From owner-dhcp-v6@bucknell.edu  Fri Sep  1 09:47:01 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11850
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 1 Sep 2000 09:47:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e81Df9i21621;
	Fri, 1 Sep 2000 09:41:54 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e81Df1i14246
	for <dhcp-v6@bucknell.edu>; Fri, 1 Sep 2000 09:41:01 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <RHPT3T1L>; Fri, 1 Sep 2000 09:40:45 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC08D@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Discussion Item - Using DHCPv4 options in DHCPv6 (Item 6 on Confe
	rence Call Agenda)
Date: Fri, 1 Sep 2000 09:40:45 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

During the DHCPv6 conference call on Thursday, August 31st, I was assigned
the "responsibility" of coming to a resolution on item 6 on Ralph's compiled
list:

6. Where appropriate, keep v4 and v6 options/extensions "the
    same". Use the same option numbers. Use the same format (except for
    16-bit type/length).

As I was one of the people that proposed this, let me give you my reasons.

While there are many options in DHCPv4 that are no appropriate to DHCPv6
(either because the options configure things that aren't appropriate or
don't exist in IPv6 or because they contain internet addresses), there are
many other options that are appropriate to both (such as domain names and
URLs). I'm not proposing that all DHCPv4 options be valid in DHCPv6. I'm
just proposing that we reserve option (or extension) numbers from 0 to 255
in DHCPv6 and adopt any of the DHCPv4 options that make sense in DHCPv6 and
use the same option numbers.

>From some point forward, all new DHCP options RFCs should have a statement
that indicates whether the option is valid in DHCPv4 and/or DHCPv6. And, for
those that are appropriate to DHCPv4, we use whatever limitations exist on
the number space (<256). For DHCPv6 only options, any number is valid.

For existing DHCPv4 options that are also valid for DHCPv6, we now only need
to write a document that indicates what these options are and that the
format of the option data is the same, though the option header now uses
16-bit option number and length. We don't have to re-specify the behavoir of
the client and server with respect to these options. Note also that while we
may feel that having DHCPv6 options for the DHCPv4 NDS ones makes little
sense, perhaps someone will find a need. In that case, they could easily
issue a 1 page draft (excluding the draft boiler-plate requirements) that
says DHCPv4 option x is valid on DHCPv6 with a 16-bit option number and
length. I think we'd all agree that reviewing these drafts is much easier
and faster than having to review the entire text again (since we'd then
likely want to add other rewording, etc.).

I am not proposing that we re-format the data of options (such as those that
carry internet addresses) for those would not work "as is" for DHCPv6. If
DHCPv6 needs that option, a new option should be defined to carry the data
appropriate to DHCPv6. Only those options where the data can be used "as is"
should be adopted in DHCPv6.

IANA must also only assign numbers from ONE space instead of having two
option spaces (DHCPv4 and DHCPv6) to consider. Though, IANA would need to be
instructed that options that apply to DHCPv4 would need to be assigned from
the current DHCPv4 space (0..127) and that DHCPv6 only options must be
assigned numbers >255.

This also allows for simplier configuration of DHCP servers should a server
support both DHCPv4 and DHCPv6. Or in storing options data in a database or
LDAP repository (as an author of the LDAP schema for DHCP, I'd like us not
to have a "dhcpv4option" and "dhcpv6option" attribute - much easier to have
just a "dhcpoption" attribute which can store either).

Doing the work do go through all of the DHCPv4 options to determine
applicability to DHCPv6 is likely not an easy task. So, my suggestion is
that as we develop the options we want for DHCPv6, we look to the DHCPv4
options. If we find an identical option in DHCPv4, we use that option number
and option data format. If someone later wants to add another option, they
write that 1 page draft I mentioned earlier.

What's the impact to DHCPv6 for doing this? I think almost nothing except to
reserve options 0 to 255 and use the DHCPv4 option numbers (and data format)
if and only if appropriate.

So, with that ... let's start the discussion. As we did not set a deadline
at the conference call, other than stating a week, and given the Labor Day
holiday, I'd like to conclude this discussion by end of day Friday,
September 8.

- Bernie Volz
  IPWorks, Inc.



From owner-dhcp-v6@bucknell.edu  Fri Sep  1 09:52:54 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11995
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 1 Sep 2000 09:52:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e81DqKi24615;
	Fri, 1 Sep 2000 09:52:20 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e81DqBi21594
	for <dhcp-v6@bucknell.edu>; Fri, 1 Sep 2000 09:52:11 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <RHPT3TFP>; Fri, 1 Sep 2000 09:51:56 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC08E@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Co
	nference Call Agenda)
Date: Fri, 1 Sep 2000 09:51:55 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

During the DHCPv6 conference call on Thursday, August 31st, I was assigned
the "responsibility" of coming to a resolution on reconfiguration in DHCPv6
(items 8, 9, and 18 on Ralph's compiled list):

8. Allow Reconfigure and Reconfigure-reply messages to be sent via a
    relay to client's which do not have such reachable IP addresses, in
    order to inform them of changes in non-releasable resources?  The
    same thing could also go for Reconfigure-init to some extent.

9. Might a client send a Solicit in response to a Reconfigure-init?
    What if the topology changes such that this is necessary in order
    find a DHCP server with can allocate addresses on the new subnet?

18. Simplify reconfiguration; Use DHCPv4-style reconfiguration

I believe the general consensus was a desire to use the DHCPv4-style
reconfiguration (unicast from server to client). However, there is also a
desire to accommondate multicasting as for major network reconfiguration
events, unicasting may inefficient (if there are 1000's of clients to
notify). But multicasting opens up significant security issues.

Let's start the discussion. As we did not set a deadline at the conference
call, other than stating a week, and given the Labor Day holiday, I'd like
to conclude this discussion by end of day Friday, September 8.

- Bernie Volz
  IPWorks, Inc.




From owner-dhcp-v6@bucknell.edu  Fri Sep  1 10:03:36 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12267
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 1 Sep 2000 10:03:36 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e81E16i14451;
	Fri, 1 Sep 2000 10:01:06 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e81E13i08807
	for <dhcp-v6@bucknell.edu>; Fri, 1 Sep 2000 10:01:03 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA04269 for <dhcp-v6@bucknell.edu>; Fri, 1 Sep 2000 10:00:47 -0400 (EDT)
Message-Id: <4.3.1.2.20000901100107.00b31960@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 01 Sep 2000 10:03:14 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: DHCPv6 design team Conference Call Agenda
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEC08E@lespaul.process.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Bernie has posted a couple of notes referring to the design team conference 
call that took place 8/31.  I will post notes and minutes from that meeting 
this AM, along with the list of agenda items Bernie mentioned in his notes...

- Ralph



From owner-dhcp-v4@bucknell.edu  Fri Sep  1 10:51:31 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13192
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 1 Sep 2000 10:51:31 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e81Elei04763;
	Fri, 1 Sep 2000 10:47:40 -0400 (EDT)
Received: from postal.metaip.checkpoint.com (metaip.checkpoint.com [204.29.28.25])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e81ElTi26590
	for <dhcp-v4@bucknell.edu>; Fri, 1 Sep 2000 10:47:29 -0400 (EDT)
Received: from cartman.metainfo.com (cartman.metainfo.com [204.29.28.145])
	by postal.metaip.checkpoint.com (8.9.3/8.9.3VRJ666) with ESMTP id OAA21977
	for <dhcp-v4@bucknell.edu>; Sat, 2 Sep 2000 14:40:46 -0700
Received: by cartman.metainfo.com with Internet Mail Service (5.5.2650.21)
	id <RTW2NJYN>; Fri, 1 Sep 2000 07:47:27 -0700
Received: from sea.checkpoint.com (sneakers.metainfo.com [204.29.28.213]) by cartman.metainfo.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id RTW2NJYM; Fri, 1 Sep 2000 07:47:15 -0700
From: richardj@sea.checkpoint.com
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Message-ID: <39AFC172.CEC6E01E@sea.checkpoint.com>
Date: Fri, 01 Sep 2000 07:47:14 -0700
Organization: Checkpoint Software Technologies
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: Authentication option
References: <Pine.SOL.4.21.0008312050250.18547-100000@codex.cis.upenn.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: richardj@sea.checkpoint.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

That sounds to me like the clearest expression of the
problem and its solution so far - I'd like to see it go
into the draft. It supports the issue in a 'framework-like'
manner, in keeping with the rest of the draft.

Richard

"William A. Arbaugh" wrote:

> I propose the following:
>
> 1. An authentication mis-match should be treated in a similar fashion as
> if the server did not include authentication information.  Any thing
> further and we're going done the security association negotiation trail
> (and it's a long one).
>
> 2. While I don't like the idea of accepting packets where the
> authentication option failed to verify, the server could just as well have
> sent the packet without authentication information and we would accept it
> (assumming the client would accept un-authenticated packets).  Therefore,
> I propose that:
>         a. If the client is configured to accept un-authenticated packets,
> then it MAY accept (if further configured) authenticated packets that
> fail to verify.  We should stress that this is very dangerous and is only
> done for the sake of robustness.
>         b. If the client is configured NOT to accept un-authenticated
> packets, then the client MUST NOT accept authenticated packets that fail
> to verify.
>
> Bill



From owner-dhcp-v6@bucknell.edu  Fri Sep  1 16:30:41 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19634
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 1 Sep 2000 16:30:38 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e81KPFi25056;
	Fri, 1 Sep 2000 16:25:15 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e81KPDi17584
	for <dhcp-v6@bucknell.edu>; Fri, 1 Sep 2000 16:25:13 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA21056 for <dhcp-v6@bucknell.edu>; Fri, 1 Sep 2000 16:24:56 -0400 (EDT)
Message-Id: <4.3.1.2.20000901160948.00b30100@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 01 Sep 2000 16:27:19 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Design team teleconference, 8/31
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

We held a DHCPv6 spec design team teleconference on 8/31.  The purpose of 
the teleconference was to develop a plan for getting the spec ready for 
final WG review in San Diego, followed by a WG last call in early 
January.  To meet that goal, we put together a calendar of milestones to be 
accomplished over the next four months and a list of issues that need to be 
resolved in the current spec.

This message will summarize the outcomes of the meeting.  I will follow up 
with a list of discussion items and dispositions later today and a full set 
of minutes early next week.


Participants:

Mark Stapp          mjs@cisco.com
Rich Woundy         rwoundy@cisco.com
Michael Carney      Michael.Carney@eng.sun.com
Jim Bound           bound@zk3.dec.com
Bernie Volz         Volz@ipworks.com
Richard Jones       richardj@metaip.checkpoint.com
Thomas Narten       narten@raleigh.ibm.com
Ted Lemon           mellon@isc.org
Barr Hibbs          rbhibbs@ultraDNS.com
Bernard Aboba       baboba@internaut.com
Francis Dupont      Francis.Dupont@enst-bretagne.fr
Josh Littlefield    joshl@cisco.com
Subir Das           subir@mailee.research.telcordia.com
Tony McAuley        mcauley@research.telcordia.com
Ralph Droms         rdroms@cisco.com


Outcomes:

Milestones and calendar
-----------------------
  9/30/2000 Publish revised spec, with changes
            based on design team teleconference
10/10/2000 Interim WG meeting to review revised
            spec
11/15/2000 Publish final spec for WG review in
            San Diego, based on input from WG
            review on 10/10
12/1x/2000 Final WG review in San Diego
  1/ 5/2001 WG last call


Discussion Issues
-----------------
We discussed the following issues, which were generated from design team 
input prior to the teleconference.  The issue numbers are from the original 
list of issues; the design team edited the list during the teleconference 
to generate this final list.

The design team performed a triage on the list of issues, dividing the list 
into

YES         - do it now
FUTURE WORK - consider in future
<name>      - responsible person
TRANS. DOC  - include in a (yet-to-be-written)
               transition doc
DEFER       - reconsider later for current doc

YES     1. Use of multicast instead of broadcast

TED     2. Use of globally-unique "client identifier": link-local
            address may not be sufficiently "permanent" for client lease
            identification
         20. Support a client-identifier hierarchy, a la DHCPv4.

DEFER   3. Cleaner and simpler message formats.
         10. Smaller DHCP message header for B/W efficiency.
         16. A single fixed header for (at least) Solicit, Advertise,
             Request, Reply, and Release messages, rather than
             different headers for different messages, with most
             information in extensions; get rid of mode bits wherever
             possible; multi-bit numbers should be 8, 16, 32, 64 or 128
             bits; there should be no reserved fields in extensions.
         27. Any bits in extensions that change the meaning of the
             extension type for the whole extension should be
             represented as new extensions.
         28. The client, when it is referring to an address it wants to
             renew, should be able to reflect back at the server the
             exact IP Address extension that it got from the server,
             rather than having to tweak it.


YES     4. Avoid stateful server (in terms of the protocol
            interaction).  Clarifications:
            - Correct server operation will not depend on XID
            - Clients will use XID consistently to allow for server
              optimizations

YES     5. Reduce number of ways to release resources

BERNIE  6. Where appropriate, keep v4 and v6 options/extensions "the
            same". Use the same option numbers. Use the same format
            (except for 16-bit type/length).

FUTURE  7. Define DHCPng as ONE new protocol can that can accommodate
WORK       IPv4 and IPv6 address assignments.


YES     18. Simplify reconfiguration; Use DHCPv4-style reconfiguration
         8. Allow Reconfigure and Reconfigure-reply messages to be sent
            via a relay to client's which do not have such reachable IP
            addresses, in order to inform them of changes in
            non-releasable resources?  The same thing could also go for
            Reconfigure-init to some extent.
         9. Might a client send a Solicit in response to a
            Reconfigure-init?  What if the topology changes such that
            this is necessary in order find a DHCP server with can
            allocate addresses on the new subnet?
BERNIE  -  Implement multicast reconfigure?

MARK    11. Reduce the number of messages to configure a node; e.g.
             - a two-message lease binding
             - permitting a client to obtain 1-n addresses as needed
               rather than all at "boot" time

FUTURE  12. To rapidly configure roaming users, avoid ND Neighbor
WORK        Solicitation and Neighbor Advertisement, both for the link
             local addresses and the address given by DHCP.

FUTURE  13. Configure a router's interface if it is on the same link
WORK        as the DHCP server.

FUTURE  14. Define a new interface to DHCP for doing things such as
WORK        adding a new address pool, changing some configuration
             parameters, or being able to request a new address pool.

DEFER   15. No state transition diagram in spec

YES     17. Use the delayed authentication mechanism that dhcpv4 has
             been developing.

FUTURE  19. Consider IPv6 address compression.
WORK

TED     21. Address model:
             * One interface, with a single unique identifier, can be
               assigned multiple addresses
             * Server knows exactly what addresses to assign to client
             * Client asks for "configuration", which includes assigned
               addresses
             * Client may extend leases on addresses individually

TED     22. Messages and semantics
             * Rename messages and change semantics to match RFC2131
             * Use message exchanges from RFC2131
             * Change formats to optimize message size and carry IPv6
               addresses
         30. Why 'extensions' and not 'options'?

BARR    23. Relay agents - adopt DHCPv4 function: relay agents insert
             interface address in 'giaddr' and forward to DHCP servers
         26. Relay agents should simply encapsulate the client message
             in a DHCPv6 extension; the relay message should have its
             own type.

YES     24. Discard references to "releasable resources"

FUTURE  29. Releasable resources should be documented in a separate
WORK        draft.

TRANS.  25. What happens when the network type is ambiguous - could be
DOC         IPv6, could be IPv4.







From owner-dhcp-v4@bucknell.edu  Tue Sep  5 01:56:10 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18108
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 5 Sep 2000 01:56:09 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e855p0i22902;
	Tue, 5 Sep 2000 01:51:00 -0400 (EDT)
Received: from web702.mail.yahoo.com (web702.mail.yahoo.com [128.11.23.22])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e855ovi24371
	for <dhcp-v4@bucknell.edu>; Tue, 5 Sep 2000 01:50:57 -0400 (EDT)
Received: (qmail 28186 invoked by uid 60001); 5 Sep 2000 05:55:10 -0000
Message-ID: <20000905055510.28185.qmail@web702.mail.yahoo.com>
Received: from [165.228.129.11] by web702.mail.yahoo.com; Mon, 04 Sep 2000 22:55:10 PDT
Date: Mon, 4 Sep 2000 22:55:10 -0700 (PDT)
From: =?iso-8859-1?q?Roni=20Marks?= <rapid11@yahoo.com>
Subject: DNS and DHCP servers
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Reply-To: rapid11@yahoo.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 8bit

Could someone explain how a host can keep its name
permanently in the case that a DHCP server is to
assign it an IP address?

Any responses would be greatly appreciated.

Andrew Smiles
rapid11@yahoo.com
Sydney, Australia

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/



From owner-dhcp-v4@bucknell.edu  Tue Sep  5 09:59:19 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02380
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 5 Sep 2000 09:59:18 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e85DmTi07170;
	Tue, 5 Sep 2000 09:48:31 -0400 (EDT)
Received: from relay02.rabobank.nl (relay02.rabobank.nl [145.72.69.21])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e85Dlwi20190
	for <dhcp-v4@bucknell.edu>; Tue, 5 Sep 2000 09:47:58 -0400 (EDT)
Received: from 172.31.65.109 by relay02.rabobank.nl with ESMTP (
 WorldSecure Server SMTP Relay(WSS) v4.5); Tue, 05 Sep 2000 15:44:01
 +0200
X-Server-Uuid: d32dbd14-b86d-11d3-8c8e-0008c7bba343
Received: by corvus.rf.rabobank.nl with Internet Mail Service (
 5.5.2650.21) id <S2AH8R8Y>; Tue, 5 Sep 2000 15:47:08 +0200
Message-ID: <4DD4836FE7B6D311AC1B00508B61656C7F06C4@pyxis.rf.rabobank.nl>
From: "Boersma, A (Abe)" <A.Boersma@rf.rabobank.nl>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: IP conflict
Date: Tue, 5 Sep 2000 15:47:05 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 15AA272A643236-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Reply-To: A.Boersma@rf.rabobank.nl
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

Hi,

Hopefully someone can help me out here.
At my office we have about 10.000 workstations and PC's. Most of them are
Windows95/osr2.
About 75% of these PC use DHCP. We use the Microsoft DHCP Server on NT 4.
Now when you have as much PC's as we do your bound to run into duplicate
error messages on the Windows95 stations. And so we do about once every two
weeks. Somehow to me it seems as if the Windows95 implementation of the DHC
Protocol refuses to let go of it's previous IP adress and simply want
continue working when the DHCP servers NACKS it's renewal request. What we
do now is is we give this machine a static IP adress for a period of a week,
and then return it to DHCP. This works most of the time but just doesn't
seem the best solution for this problem. Can anyone tell me what i can do
best in these cases. Also can someone tell me if my suspison about the
Windows95 implementation fo DHCP is kinda wrong, and if this is better of
fixed in Windows NT?

Thanks a lot

Abe Boersma
Rabofacet
the Netherlands
a.boersma@rf.rabobank.nl

================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en 
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en 
de afzender direct te informeren door het bericht te retourneren. 
================================================
The information contained in this message may be confidential 
and is intended to be exclusively for the addressee. Should you 
receive this message unintentionally, please do not use the contents 
herein and notify the sender immediately by return e-mail.



From owner-dhcp-v4@bucknell.edu  Tue Sep  5 10:20:15 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03062
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 5 Sep 2000 10:20:15 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e85EJPi16977;
	Tue, 5 Sep 2000 10:19:25 -0400 (EDT)
Received: from gw-us3.philips.com (gw-us3.philips.com [205.167.15.10])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e85EJAi04180
	for <dhcp-v4@bucknell.edu>; Tue, 5 Sep 2000 10:19:10 -0400 (EDT)
Received: from smtprelay-us2.philips.com (localhost.philips.com [127.0.0.1])
          by gw-us3.philips.com with ESMTP id JAA14503;
          Tue, 5 Sep 2000 09:19:03 -0500 (CDT)
          (envelope-from dan.forthun@philips.com)
From: dan.forthun@philips.com
Received: from smtprelay-nam2.philips.com(167.81.233.16) by gw-us3.philips.com via mwrap (4.0a)
	id xma014498; Tue, 5 Sep 00 09:19:03 -0500
Received: from AMLMS01.DIAMOND.PHILIPS.COM (amlms01sv1.diamond.philips.com [161.88.79.213]) 
	by smtprelay-us2.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id JAA26964; Tue, 5 Sep 2000 09:19:02 -0500 (CDT)
Received: by AMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi
          via AMEC id 0056910007014043; Tue, 5 Sep 2000 09:21:21 -0500
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: IP conflict
Message-ID: <0056910007014043000002L132*@MHS>
Date: Tue, 5 Sep 2000 09:21:21 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; name="MEMO 09/05/00 09:26:21"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id e85EJCi16791
Reply-To: dan.forthun@philips.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 8bit

Hi Abe,

You can run the dos command "winipcfg".  A pop up menu will come up and this has a button on it that says "release all".  Select it and this will release the IP address then click on "renew all" to request another address from the dhcp server.

Dan




A.Boersma@rf.rabobank.nl@SMTP@bucknell.edu on 09/05/2000 07:53:04 AM
Please respond to A.Boersma@rf.rabobank.nl@SMTP 
Sent by:	owner-dhcp-v4@bucknell.edu
To:	dhcp-v4@bucknell.edu@SMTP
cc:	 
Subject:	IP conflict
Classification:	Restricted
Hi,

Hopefully someone can help me out here.
At my office we have about 10.000 workstations and PC's. Most of them are
Windows95/osr2.
About 75% of these PC use DHCP. We use the Microsoft DHCP Server on NT 4.
Now when you have as much PC's as we do your bound to run into duplicate
error messages on the Windows95 stations. And so we do about once every two
weeks. Somehow to me it seems as if the Windows95 implementation of the DHC
Protocol refuses to let go of it's previous IP adress and simply want
continue working when the DHCP servers NACKS it's renewal request. What we
do now is is we give this machine a static IP adress for a period of a week,
and then return it to DHCP. This works most of the time but just doesn't
seem the best solution for this problem. Can anyone tell me what i can do
best in these cases. Also can someone tell me if my suspison about the
Windows95 implementation fo DHCP is kinda wrong, and if this is better of
fixed in Windows NT?

Thanks a lot

Abe Boersma
Rabofacet
the Netherlands
a.boersma@rf.rabobank.nl

================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en
de afzender direct te informeren door het bericht te retourneren.
================================================
The information contained in this message may be confidential
and is intended to be exclusively for the addressee. Should you
receive this message unintentionally, please do not use the contents
herein and notify the sender immediately by return e-mail.




From owner-dhcp-v6@bucknell.edu  Wed Sep  6 03:35:53 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05205
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 03:35:38 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e867Voi28839;
	Wed, 6 Sep 2000 03:31:51 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e867VYi13839
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 03:31:35 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-139.ip.theriver.com [206.97.58.139]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id GAA03052 for <dhcp-v6@bucknell.edu>; Tue, 5 Sep 2000 06:38:07 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e867TfC01827 for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 00:29:42 -0700 (MST)
Message-Id: <200009060729.e867TfC01827@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6 address model proposal...
Date: Wed, 06 Sep 2000 00:29:41 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


We talked a bit about the DHCPv6 address model at the end of the
conference call, and I think we sort of all knew what we were talking
about, but it's not entirely clear.  I think there are two aspects to
this: to what form of identification are addresses bound, what sort of
address requests are permissible, and who decides what to do?

I think there are actually only two questions a client ever needs to
ask the server: "please associate an IP address with this identity,"
and "please renew the association for this identity."   In the current
DHCPv6 model, "this identity" is the local link address, although
there are limitations to this model that need to be discussed
seperately.   Anyway, I'm going to call the association between a
client-supplied identity and the client's IP address an "identity
association."

One complication with IPv6 is that globally-routable addresses can
have prefixes that change over time.   DHCPv6 seems to need a
mechanism to support this.   When the DHCP server is asked to renew an
association with a given identity, it may be that there is an old
prefix that is still usable but deprecated, that the DHCP server
should renew for the client just in case the client is still using it,
and there may also be a new prefix that the client should be told to
use for all new connections.   The time when the leases on each of
these addresses expires may be different - the deprecated address may
not be valid for the full duration of the lease on the recommended
address.

It's hard to solve this problem in a way that isn't really hairy.   I
know this from trying to state a solution, and also from having
watched the draft authors and the WG chair wrestle with this issue in
the past.   I don't have a trivially simple model to propose.   What I
will propose is this:

Each identity association can have more than one IP address associated
with it, but except for the deprecated/non-deprecated status of these
IP addresses, all of the IP addresses are semantically equivalent.
Each address, recommended or deprecated, comes with an individual
lease.  The identity association comes with a seperate renewal time.
It's possible for any address in an identity association to expire
before the renewal time on that association, and it's very likely that
a deprecated address would expire before this renewal time, and very
unlikely that a recommended address would.

The server tells the client what addresses it has for an identity
association - the client can't say "I'd like three".  This choice is
based strictly on the network topology - the server is not giving the
client three addresses to do three different things with.

If the client wants to have IP addresses that have different meanings,
it generates more than one identity.  That is, if the client wants to
be able to listen on one IP address and provide service for
www.arf.org, and on another IP address and provide service for
www.blaznorf.edu, it creates two seperate identities, and it maintains
completely seperate state machines for two seperate identity
associations.  The server doesn't need to know that the two identities
are related, although we may want to make it *possible* for the server
to know that they are related.

There is also the question of when the client can ask for addresses.
I think the answer is "anytime".  It should be possible to fork a new
identity association at the request of an application, and to get rid
of it later at the request of the application.   It should be possible
for the DHCP client to generate an identity association for each
network interface at boot time.   I don't think we need to specify
this, other than to say "the client gets to decide when it does this."

As to the question of synchronization between identity associations, I
don't think it's possible, although it's a seductive idea.  I think
the DHCP client should send seperate packets for each identity
association.  We could make it optionally possible to combine requests
on behalf of more than one identity association, but I think this
costs us some complexity and I can't see any way that it helps us,
beyond perhaps the initial packet requesting addresses for each
identity association.   It would be nice if the DHCP server could
present a uniform set of extensions that is consistent across identity
associations, but I don't see any way to specify this that is helpful
- I think this is a topic for future research.

One interesting fallout from having a renewal time on the identity
association rather than on the address is that it means that the
server can respond with zero IP addresses and a renewal time, forcing
the client to wait some period of time without getting an IP address,
and then try again.   I don't know if we care about this - it's just
something that occurred to me.   We have talked about similar
functionality for DHCPv4 in the past, but I don't get the impression
that everybody thinks this is a good idea.

So I have two questions: first, does this presentation make sense, or
have I left out things that are obvious to me but not to the reader.
Second, if it makes sense, is it the right thing to do?   What do we
need to change?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 03:47:13 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05329
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 03:47:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e867kmi15902;
	Wed, 6 Sep 2000 03:46:48 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e867kWi32366
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 03:46:33 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-139.ip.theriver.com [206.97.58.139]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id GAA03079 for <dhcp-v6@bucknell.edu>; Tue, 5 Sep 2000 06:53:07 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e867idC01841 for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 00:44:39 -0700 (MST)
Message-Id: <200009060744.e867idC01841@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: DHCPv6 client identification...
Date: Wed, 06 Sep 2000 00:44:39 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


We had a nice discussion about client identifiers during the
conference call.  The issues that I remember us talking about are:

	(a) Giving a DHCP client a unique identification that does
	    not change when network hardware changes
	(b) Providing a way to identify more than one instance of
	    usage (I called these identity associations in my message
	    about the DHCPv6 address model) within an individual client.
	(c) Providing a way for the server to tell that two identity
	    associations actually represent one client.
	(d) Providing a way to have a single authentication
	    key work with all of a client's identity associations.

For (a), we seem to have pretty much agreed that we need a
universally-unique identifier, similar to what Intel has done in the
PXE specification.

We can solve (b) by having the client come up with more than one
UUID.   However, to solve (c) and (d), it would be better if we
defined a way to have the DHCP client specify a UUID and then specify
a modifier to that UUID, so that the identity association would
actually be made up of {modifier, UUID}.   Authentication would be
done based on {UUID}, not on {modifier, UUID}, and the server could
therefore tell that two identity associations are the same client by
noticing that although the modifier is different, the UUID is the
same.

In order to avoid creating the possibility of namespace clashes, I'd
suggest that we specify the modifier as a 16-bit number, defined by
the client, that's just an index.   So if a DHCP client had two
network interfaces, its two identity associations would probably be
{0, UUID} and {1, UUID}.

There is one problem with this: if the DHCP client is not consistent
about assigning prefixes, it would be possible for it to assign {0,
UUID} to one network interface one time, and {1, UUID} to that network
interface the next time.   This shouldn't be a huge problem for a
typical client, but for fancy clients the client implementor might
want to actually maintain its own mapping between the network hardware
address and the index.

It might also make sense to have the modifier be an 8-bit interface
index and an 8-bit application index, with application index == 0
always being the initial configuration for that interface.   So a
typical client with two network interfaces would have these two
identity associations: {0, 0, UUID} and {1, 0, UUID}.   And if an
application decided to listen with its own address on each interface,
then the client would have four identity associations: {0, 0, UUID},
{0, 1, UUID}, {1, 0, UUID} and {1, 1, UUID}.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 11:23:17 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14892
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 11:23:16 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86FJKi18834;
	Wed, 6 Sep 2000 11:19:20 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86FJCi08601
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 11:19:13 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <S2PLQR54>; Wed, 6 Sep 2000 11:18:56 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC0B0@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Wed, 6 Sep 2000 11:18:54 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted:

I think you almost have it.

I was thinking more of a model that would have the client/server maintain
lists that have three main entries - the address assignment ID, the address,
and the expiration time.

When a client requests [new] address(es) it sends a request with an address
assignment ID (we may allow it to be absent or "null"). It is assigned any
number of addresses (0 to n). Each of these addresses may expire at
different times.

When a client needs to renew one or more addresses, it sends the address
assignment ID and the list of addresses (which may be 1 to n). It need NOT
renew all of the addresses at once (since they may each expire at different
times). Note that a request with the address assignment ID and 0 addresses
means that the client doesn't know what addresses it has and thus the server
would send it *ALL* of the addresses it wants to allocate for that client's
address assignment ID.

Bookkeeping is rather simple - when an address expires, that entry is
removed.

A client MAY also renew each address (even if multiple ones use the same
address assignment ID) individually.

I also think that a client should be able to ask for "specific" addresses.
The way it does this is that is supplies the "address" option but provides
an INCOMPLETE address (for IPv6, this is one with a prefix length of less
than 128; for IPv4, this is one with a mask length of less than 32?). Since
these are incomplete addresses, the server knows that this is a "subnet
selection" type request and can supply those addresses (if available to the
client); the server MAY supply any number of other addresses it deems the
client should have.

I also believe that we should have a "magic" address assignment ID such that
a server knows that this is the "basic" set of addresses for the client.
This could be the "null" (or absent) address assignment ID. I think this has
value in that a server may want to know to give out single addresses for
non-"magic" address assignment IDs since these are likely for application
specific purposes and thus a single address likely suffices. I'm not
suggesting that we require this; just that it would be helpful for the
client and server to agree on what is a "basic" address request.

I agree with you that a request should be simple and we should not allow a
request to include multiple address assignment IDs. Otherwise, the
processing at the server becomes rather complex. And, a request should
either renew one or more addresses or request "new" addresses, not both.

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Wednesday, September 06, 2000 3:30 AM
To: DHCPv6 discussion list
Subject: DHCPv6 address model proposal...



We talked a bit about the DHCPv6 address model at the end of the
conference call, and I think we sort of all knew what we were talking
about, but it's not entirely clear.  I think there are two aspects to
this: to what form of identification are addresses bound, what sort of
address requests are permissible, and who decides what to do?

I think there are actually only two questions a client ever needs to
ask the server: "please associate an IP address with this identity,"
and "please renew the association for this identity."   In the current
DHCPv6 model, "this identity" is the local link address, although
there are limitations to this model that need to be discussed
seperately.   Anyway, I'm going to call the association between a
client-supplied identity and the client's IP address an "identity
association."

One complication with IPv6 is that globally-routable addresses can
have prefixes that change over time.   DHCPv6 seems to need a
mechanism to support this.   When the DHCP server is asked to renew an
association with a given identity, it may be that there is an old
prefix that is still usable but deprecated, that the DHCP server
should renew for the client just in case the client is still using it,
and there may also be a new prefix that the client should be told to
use for all new connections.   The time when the leases on each of
these addresses expires may be different - the deprecated address may
not be valid for the full duration of the lease on the recommended
address.

It's hard to solve this problem in a way that isn't really hairy.   I
know this from trying to state a solution, and also from having
watched the draft authors and the WG chair wrestle with this issue in
the past.   I don't have a trivially simple model to propose.   What I
will propose is this:

Each identity association can have more than one IP address associated
with it, but except for the deprecated/non-deprecated status of these
IP addresses, all of the IP addresses are semantically equivalent.
Each address, recommended or deprecated, comes with an individual
lease.  The identity association comes with a seperate renewal time.
It's possible for any address in an identity association to expire
before the renewal time on that association, and it's very likely that
a deprecated address would expire before this renewal time, and very
unlikely that a recommended address would.

The server tells the client what addresses it has for an identity
association - the client can't say "I'd like three".  This choice is
based strictly on the network topology - the server is not giving the
client three addresses to do three different things with.

If the client wants to have IP addresses that have different meanings,
it generates more than one identity.  That is, if the client wants to
be able to listen on one IP address and provide service for
www.arf.org, and on another IP address and provide service for
www.blaznorf.edu, it creates two seperate identities, and it maintains
completely seperate state machines for two seperate identity
associations.  The server doesn't need to know that the two identities
are related, although we may want to make it *possible* for the server
to know that they are related.

There is also the question of when the client can ask for addresses.
I think the answer is "anytime".  It should be possible to fork a new
identity association at the request of an application, and to get rid
of it later at the request of the application.   It should be possible
for the DHCP client to generate an identity association for each
network interface at boot time.   I don't think we need to specify
this, other than to say "the client gets to decide when it does this."

As to the question of synchronization between identity associations, I
don't think it's possible, although it's a seductive idea.  I think
the DHCP client should send seperate packets for each identity
association.  We could make it optionally possible to combine requests
on behalf of more than one identity association, but I think this
costs us some complexity and I can't see any way that it helps us,
beyond perhaps the initial packet requesting addresses for each
identity association.   It would be nice if the DHCP server could
present a uniform set of extensions that is consistent across identity
associations, but I don't see any way to specify this that is helpful
- I think this is a topic for future research.

One interesting fallout from having a renewal time on the identity
association rather than on the address is that it means that the
server can respond with zero IP addresses and a renewal time, forcing
the client to wait some period of time without getting an IP address,
and then try again.   I don't know if we care about this - it's just
something that occurred to me.   We have talked about similar
functionality for DHCPv4 in the past, but I don't get the impression
that everybody thinks this is a good idea.

So I have two questions: first, does this presentation make sense, or
have I left out things that are obvious to me but not to the reader.
Second, if it makes sense, is it the right thing to do?   What do we
need to change?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 14:13:17 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19617
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 14:13:09 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86I6Ci15673;
	Wed, 6 Sep 2000 14:06:12 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86I60i15396
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 14:06:00 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <S2PLQSGZ>; Wed, 6 Sep 2000 14:05:44 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC0B6@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 client identification...
Date: Wed, 6 Sep 2000 14:05:34 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted:

Why do you need an interface index? Unless we expect a client to have more
than one interface connected to a single subnet, do we really need this? The
interface identifier is implied by the source of the client's request at the
server (giaddr or received interface).

I suppose that if we want to be really robust, the interface index is
useful. However, why not just use some opaque identifier such as the
hardware (or link local in IPv6) address. This avoids the problem of
interface number, since the number may not always be fixed (ie, if I add a
new interface to a system, it might change what was interface 1 to interface
2). There is the problem of devices without hardware addresses, but these
could fall back to an index as you indicated. The only problem with using
the hardware address is probably its length. But, then again you already
need to include SOME information for the server to be able to communicate
back to the client, so if this same piece of information were used, you're
all set.

I also suggest we don't limit the application index to any fixed length. We
could certainly specify a limit (such as 16 bytes), but why not let the
client implement pick what it wants. And, as I mentioned in my reply to the
address model proposal, I'd suggest using a null (or absent) application
index to mean the default. That way, we don't argue as to whether it is 0 or
1 or whatever. It's also nice since it reduces the size of the normal
(default case) messages since there is no need to include it.

The exact format of how this information is communicated hasn't been
specifically stated. Let me suggest:
- The unique client identification (only) is sent in an option/extension.
- The application index (or address index or whatever) is also sent as a
SEPARATE option/extension.
- The interface index is based on the whatever link-layer information is
sent by the client to allow the server to communicate with it (in IPv6, the
link local address). This would likely be carried in the packet header since
it will be required.


- Bernie Volz


-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Wednesday, September 06, 2000 3:45 AM
To: DHCPv6 discussion list
Subject: DHCPv6 client identification...



We had a nice discussion about client identifiers during the
conference call.  The issues that I remember us talking about are:

	(a) Giving a DHCP client a unique identification that does
	    not change when network hardware changes
	(b) Providing a way to identify more than one instance of
	    usage (I called these identity associations in my message
	    about the DHCPv6 address model) within an individual client.
	(c) Providing a way for the server to tell that two identity
	    associations actually represent one client.
	(d) Providing a way to have a single authentication
	    key work with all of a client's identity associations.

For (a), we seem to have pretty much agreed that we need a
universally-unique identifier, similar to what Intel has done in the
PXE specification.

We can solve (b) by having the client come up with more than one
UUID.   However, to solve (c) and (d), it would be better if we
defined a way to have the DHCP client specify a UUID and then specify
a modifier to that UUID, so that the identity association would
actually be made up of {modifier, UUID}.   Authentication would be
done based on {UUID}, not on {modifier, UUID}, and the server could
therefore tell that two identity associations are the same client by
noticing that although the modifier is different, the UUID is the
same.

In order to avoid creating the possibility of namespace clashes, I'd
suggest that we specify the modifier as a 16-bit number, defined by
the client, that's just an index.   So if a DHCP client had two
network interfaces, its two identity associations would probably be
{0, UUID} and {1, UUID}.

There is one problem with this: if the DHCP client is not consistent
about assigning prefixes, it would be possible for it to assign {0,
UUID} to one network interface one time, and {1, UUID} to that network
interface the next time.   This shouldn't be a huge problem for a
typical client, but for fancy clients the client implementor might
want to actually maintain its own mapping between the network hardware
address and the index.

It might also make sense to have the modifier be an 8-bit interface
index and an 8-bit application index, with application index == 0
always being the initial configuration for that interface.   So a
typical client with two network interfaces would have these two
identity associations: {0, 0, UUID} and {1, 0, UUID}.   And if an
application decided to listen with its own address on each interface,
then the client would have four identity associations: {0, 0, UUID},
{0, 1, UUID}, {1, 0, UUID} and {1, 1, UUID}.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 15:06:48 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20889
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 15:06:48 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86J3ti06489;
	Wed, 6 Sep 2000 15:03:55 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86J3Mi31039
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 15:03:22 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-242.ip.theriver.com [206.97.58.242]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id SAA04421 for <dhcp-v6@bucknell.edu>; Tue, 5 Sep 2000 18:09:53 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e86J1HF01433 for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 12:01:23 -0700 (MST)
Message-Id: <200009061901.e86J1HF01433@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 client identification... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Wed, 06 Sep 2000 14:05:34 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC0B6@lespaul.process.com> 
Date: Wed, 06 Sep 2000 12:01:17 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Why do you need an interface index? Unless we expect a client to have more
> than one interface connected to a single subnet, do we really need this? The
> interface identifier is implied by the source of the client's request at the
> server (giaddr or received interface).

I am trying to get away from the notion that an IP address is uniquely
identified by {client identifier, physical network}.   This causes
lots of obnoxious ambiguity in RFC2131 that I don't think adds any
value - to correctly implement the protocol, I have to allow clients
to have active leases with the same client identifier on different
physical networks at the same time, which means that when a client
moves from physical network to physical network within the same
administrative domain, the server may wind up with active leases for
that client on more than one network when the client is only connected
to one network.   Having one identity association per network
interface avoids this problem - if you are multiply attached, you'll
have multiple identity associations, and if you're singly attached, I
can nuke your old lease when you change networks.

Why have an interface index?   I'm trying to avoid a situation where
you have a client with lots of network interfaces that change around -
e.g., a laptop that has an ethernet card and an 802.11 card that get
swapped in and out - that winds up not being able to keep a static
address, or winds up consuming extra addresses, because the DHCP
client doesn't maintain a consistent identification for each
interface.   Consider the following sequence of events:

(1) laptop is powered on with an ethernet card in pcmcia slot 1.
(2) laptop gets IP address using DHCP for {0, UUID}
(3) application starts, requests the client to get another identity
(4) client gets that identity using {1, UUID}
(5) user inserts 802.11 card, which acquires an identity using {2, UUID}
(6) user power cycles laptop
(7) laptop gets IP address for ethernet card using {0, UUID}
(8) laptop gets IP address for 802.11 card using {1, UUID}
(9) application starts, gets its IP address using {2, UUID}

Note that the IP addresses assigned to {1, UUID} and {2, UUID} will
likely be different the second time through.

You see the problem?   Using the interface index doesn't actually
solve this problem, but it makes it less likely to happen, and it also
raises the issue in the mind of the implementor.   I'm not sure this
matters, but I mention it because I think it's useful to think about.

As for having variable-width prefixes, I think this is not a good
idea, because it invites the possibility of identifier clashes.  The
algorithm for generating a UUID may work pretty well, but it's
probably predicated on the idea that everybody will use a similar
algorithm.  So what happens when you modify this algorithm by allowing
the client to attach arbitrary strings to it?  How do you avoid the
case where {prefix1, UUID1} and {prefix2, UUID2} happen to be the same
quantity?

I can implement an algorithm that avoids this problem by doing a
two-stage hash lookup, but do we want to *require* that all DHCP
server implementors implement this more complicated algorithm?  If you
use a fixed-width prefix that is always present, I think you avoid
having to do this, and I think that's worthwhile.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 16:31:11 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22739
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 16:31:11 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86KEai17846;
	Wed, 6 Sep 2000 16:14:36 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86KEWi08495
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 16:14:32 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <S2PLQSPW>; Wed, 6 Sep 2000 16:14:16 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC0B8@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 client identification...
Date: Wed, 6 Sep 2000 16:14:13 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted ... OK, I'm in agreement with you regarding the interface identifier.
You give good reasons for this. (The one situation that might be a problem
is where a host has no stable storage or looses this and might come up with
numbering the interfaces differently  and if these are on different physical
networks yet are served by a single server, the server might find a conflict
where the "old" address for the ids isn't valid. But, that just means it has
to place that address into a weird state until the lease would expire.)

The only item I still don't fully agree with is the fixed vs variable-length
issue. I wasn't saying that I was using a PREFIX. I feel the interface id
and application id should be SEPARATE from the UUID. Each address allocation
has these three values associated with it, but they are separate items not a
single byte-string.

There is no disagreement that fixed is easier to deal with. But, I just hate
limiting ourselves today for no good reason. Are you certain that no system
(such as a server) might not want more than 256 addresses at a time for an
interface? Sure, it could change the UUID, but we want to get away from
that.

Also, if applications are going to be requesting addresses (we're all
assuming this, aren't we?), might it not be useful for the server to
potentially be configured to provide a specific address (from a pool) for a
particular application? And having that be something like "www.xyz.com" is
far more useful than having it be 1.

- Bernie Volz


-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Wednesday, September 06, 2000 3:01 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 client identification...



> Why do you need an interface index? Unless we expect a client to have more
> than one interface connected to a single subnet, do we really need this?
The
> interface identifier is implied by the source of the client's request at
the
> server (giaddr or received interface).

I am trying to get away from the notion that an IP address is uniquely
identified by {client identifier, physical network}.   This causes
lots of obnoxious ambiguity in RFC2131 that I don't think adds any
value - to correctly implement the protocol, I have to allow clients
to have active leases with the same client identifier on different
physical networks at the same time, which means that when a client
moves from physical network to physical network within the same
administrative domain, the server may wind up with active leases for
that client on more than one network when the client is only connected
to one network.   Having one identity association per network
interface avoids this problem - if you are multiply attached, you'll
have multiple identity associations, and if you're singly attached, I
can nuke your old lease when you change networks.

Why have an interface index?   I'm trying to avoid a situation where
you have a client with lots of network interfaces that change around -
e.g., a laptop that has an ethernet card and an 802.11 card that get
swapped in and out - that winds up not being able to keep a static
address, or winds up consuming extra addresses, because the DHCP
client doesn't maintain a consistent identification for each
interface.   Consider the following sequence of events:

(1) laptop is powered on with an ethernet card in pcmcia slot 1.
(2) laptop gets IP address using DHCP for {0, UUID}
(3) application starts, requests the client to get another identity
(4) client gets that identity using {1, UUID}
(5) user inserts 802.11 card, which acquires an identity using {2, UUID}
(6) user power cycles laptop
(7) laptop gets IP address for ethernet card using {0, UUID}
(8) laptop gets IP address for 802.11 card using {1, UUID}
(9) application starts, gets its IP address using {2, UUID}

Note that the IP addresses assigned to {1, UUID} and {2, UUID} will
likely be different the second time through.

You see the problem?   Using the interface index doesn't actually
solve this problem, but it makes it less likely to happen, and it also
raises the issue in the mind of the implementor.   I'm not sure this
matters, but I mention it because I think it's useful to think about.

As for having variable-width prefixes, I think this is not a good
idea, because it invites the possibility of identifier clashes.  The
algorithm for generating a UUID may work pretty well, but it's
probably predicated on the idea that everybody will use a similar
algorithm.  So what happens when you modify this algorithm by allowing
the client to attach arbitrary strings to it?  How do you avoid the
case where {prefix1, UUID1} and {prefix2, UUID2} happen to be the same
quantity?

I can implement an algorithm that avoids this problem by doing a
two-stage hash lookup, but do we want to *require* that all DHCP
server implementors implement this more complicated algorithm?  If you
use a fixed-width prefix that is always present, I think you avoid
having to do this, and I think that's worthwhile.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 16:37:05 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22864
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 16:36:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86KZni11125;
	Wed, 6 Sep 2000 16:35:50 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86KZLi13879
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 16:35:23 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-242.ip.theriver.com [206.97.58.242]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id TAA04689 for <dhcp-v6@bucknell.edu>; Tue, 5 Sep 2000 19:41:49 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e86KXBF01749 for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 13:33:12 -0700 (MST)
Message-Id: <200009062033.e86KXBF01749@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Wed, 06 Sep 2000 11:18:54 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC0B0@lespaul.process.com> 
Date: Wed, 06 Sep 2000 13:33:11 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> I also think that a client should be able to ask for "specific" addresses.
> The way it does this is that is supplies the "address" option but provides
> an INCOMPLETE address (for IPv6, this is one with a prefix length of less
> than 128; for IPv4, this is one with a mask length of less than 32?). Since
> these are incomplete addresses, the server knows that this is a "subnet
> selection" type request and can supply those addresses (if available to the
> client); the server MAY supply any number of other addresses it deems the
> client should have.

Hm.   Missed this part.   I agree that this makes sense, although I
don't grok IPv6 addressing well enough to understand exactly how this
would work.   Jim asked us to contribute actual verbiage for any
changes we want to the current spec, so I'm expecting to contribute
verbiage for the address model proposal, but I don't feel confident
that I could word this part correctly.   Could you do that?

> I also believe that we should have a "magic" address assignment ID such that
> a server knows that this is the "basic" set of addresses for the client.
> This could be the "null" (or absent) address assignment ID. I think this has
> value in that a server may want to know to give out single addresses for
> non-"magic" address assignment IDs since these are likely for application
> specific purposes and thus a single address likely suffices. I'm not
> suggesting that we require this; just that it would be helpful for the
> client and server to agree on what is a "basic" address request.

I'm afraid I don't know what you mean by a "basic" address request.
Can you expand on this?

> A request should either renew one or more addresses or request "new"
> addresses, not both.

Good point.   However, I'm not sure we actually need to add anything
to support this - really, if you want a "new" address, you're
generating a new identity association.   So the server will have to
allocate it a new address, because it never previously allocated it an
address.   If you have an old identity association, that fact in
itself means you're hoping to get back an old address, doesn't it?
Do we need to make an explicit distinction here between "new" and
"renew"?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 16:47:55 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22984
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 16:47:45 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86Kkti02624;
	Wed, 6 Sep 2000 16:46:55 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86Kkki17666
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 16:46:46 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <S2PLQSSA>; Wed, 6 Sep 2000 16:46:29 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC0BC@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Wed, 6 Sep 2000 16:46:22 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

>Jim asked us to contribute actual verbiage for any
>changes we want to the current spec, so I'm expecting to contribute
>verbiage for the address model proposal, but I don't feel confident
>that I could word this part correctly.   Could you do that?

Hm. I'm using my IPv6 knowledge that's several years old. From what I
understand, it is hopefully still valid. I can certainly try, but there may
be little need as this concept (requesting an address with a specific
prefix) is already in the DHCPv6 draft.

>I'm afraid I don't know what you mean by a "basic" address request.
>Can you expand on this?

Sure. What I meant was the request the system generates when it comes up,
instead of an application or otherwise requested allocation. All systems are
likely to request this whenever DHCP is enabled on an interface, so rather
than having them supply an identifier, make this the no (or null)
identifier. That way, a simple client that only supports "one" allocation
never has to deal with this identifier.

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Wednesday, September 06, 2000 4:33 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...



> I also think that a client should be able to ask for "specific" addresses.
> The way it does this is that is supplies the "address" option but provides
> an INCOMPLETE address (for IPv6, this is one with a prefix length of less
> than 128; for IPv4, this is one with a mask length of less than 32?).
Since
> these are incomplete addresses, the server knows that this is a "subnet
> selection" type request and can supply those addresses (if available to
the
> client); the server MAY supply any number of other addresses it deems the
> client should have.

Hm.   Missed this part.   I agree that this makes sense, although I
don't grok IPv6 addressing well enough to understand exactly how this
would work.   Jim asked us to contribute actual verbiage for any
changes we want to the current spec, so I'm expecting to contribute
verbiage for the address model proposal, but I don't feel confident
that I could word this part correctly.   Could you do that?

> I also believe that we should have a "magic" address assignment ID such
that
> a server knows that this is the "basic" set of addresses for the client.
> This could be the "null" (or absent) address assignment ID. I think this
has
> value in that a server may want to know to give out single addresses for
> non-"magic" address assignment IDs since these are likely for application
> specific purposes and thus a single address likely suffices. I'm not
> suggesting that we require this; just that it would be helpful for the
> client and server to agree on what is a "basic" address request.

I'm afraid I don't know what you mean by a "basic" address request.
Can you expand on this?

> A request should either renew one or more addresses or request "new"
> addresses, not both.

Good point.   However, I'm not sure we actually need to add anything
to support this - really, if you want a "new" address, you're
generating a new identity association.   So the server will have to
allocate it a new address, because it never previously allocated it an
address.   If you have an old identity association, that fact in
itself means you're hoping to get back an old address, doesn't it?
Do we need to make an explicit distinction here between "new" and
"renew"?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 17:27:54 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23505
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 17:27:54 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86LOvi17984;
	Wed, 6 Sep 2000 17:24:57 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86LOdi26360
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 17:24:39 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-242.ip.theriver.com [206.97.58.242]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA04804 for <dhcp-v6@bucknell.edu>; Tue, 5 Sep 2000 20:31:12 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e86LLvF01856 for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 14:21:57 -0700 (MST)
Message-Id: <200009062121.e86LLvF01856@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 client identification... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Wed, 06 Sep 2000 16:14:13 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC0B8@lespaul.process.com> 
Date: Wed, 06 Sep 2000 14:21:57 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> The only item I still don't fully agree with is the fixed vs variable-length
> issue. I wasn't saying that I was using a PREFIX. I feel the interface id
> and application id should be SEPARATE from the UUID. Each address allocation
> has these three values associated with it, but they are separate items not a
> single byte-string.

I think that they will be sent seperately.   The question is, do we
want to force the server to deal with them seperately.   Also, think
about how options are formed.   Do we want:

+-------------+-----+--------+-------------+-----+------+
| option code | len | prefix | option code | len | UUID |
+-------------+-----+--------+-------------+-----+------+

or:

+-------------+-----+--------+------+
| option code | len | prefix | UUID |
+-------------+-----+--------+------+

I think the second option is pretty desirable, so we should have a
good reason for not doing it.

> There is no disagreement that fixed is easier to deal with. But, I just hate
> limiting ourselves today for no good reason. Are you certain that no system
> (such as a server) might not want more than 256 addresses at a time for an
> interface? Sure, it could change the UUID, but we want to get away from
> that.

We could make the application prefix 16 bytes instead of 8...   I
agree that limiting things this way sounds a bit lame.

> Also, if applications are going to be requesting addresses (we're all
> assuming this, aren't we?), might it not be useful for the server to
> potentially be configured to provide a specific address (from a pool) for a
> particular application? And having that be something like "www.xyz.com" is
> far more useful than having it be 1.

Hm.   Yes, but...   Supporting a fixed association like this cleanly
opens a huge can of worms.   What if you want to move the application
to a different client?   Is there a way to tell the server that {0,
www.xyz.com, UUID1} and {0, www.xyz.com, UUID2} are the same?   How
far do you want to carry this?   I think as an academic point, you're
right, but as a pragmatic point, I don't think we're answering a
common case here, and I think that figuring out how to do this right
is a much harder problem than we should be considering, and not
something that this protocol really needs to address.   The ability to
get more than one IP address?   Sure.   The ability to do fancy
associations?   Not sure.   I think exporting this problem to the
server is too much - if the client wants consistency, it should be
responsible for maintaining it.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 17:28:55 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23558
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 17:28:55 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86LS5i03343;
	Wed, 6 Sep 2000 17:28:05 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86LQmi10436
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 17:26:48 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-242.ip.theriver.com [206.97.58.242]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA04810 for <dhcp-v6@bucknell.edu>; Tue, 5 Sep 2000 20:33:22 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e86LOgF01866 for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 14:24:42 -0700 (MST)
Message-Id: <200009062124.e86LOgF01866@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Wed, 06 Sep 2000 16:46:22 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC0BC@lespaul.process.com> 
Date: Wed, 06 Sep 2000 14:24:42 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Sure. What I meant was the request the system generates when it comes up,
> instead of an application or otherwise requested allocation. All systems are
> likely to request this whenever DHCP is enabled on an interface, so rather
> than having them supply an identifier, make this the no (or null)
> identifier. That way, a simple client that only supports "one" allocation
> never has to deal with this identifier.

But there *has* to be an identifier.  Right now it's the local link
address, but as we discussed last week, this doesn't work well,
because the local link address can change arbitrarily based on
swapping hardware.  I think we need this the *most* in the simple
case, actually.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 17:42:54 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23796
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 17:42:54 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86LgIi13188;
	Wed, 6 Sep 2000 17:42:18 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86Lg8i14012
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 17:42:08 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <S2PLQS4B>; Wed, 6 Sep 2000 17:41:51 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC0BD@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Wed, 6 Sep 2000 17:41:46 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

>> Sure. What I meant was the request the system generates when it comes up,
>> instead of an application or otherwise requested allocation. All systems
are
>> likely to request this whenever DHCP is enabled on an interface, so
rather
>> than having them supply an identifier, make this the no (or null)
>> identifier. That way, a simple client that only supports "one" allocation
>> never has to deal with this identifier.
>
>But there *has* to be an identifier.  Right now it's the local link
>address, but as we discussed last week, this doesn't work well,
>because the local link address can change arbitrarily based on
>swapping hardware.  I think we need this the *most* in the simple
>case, actually.
>
>			       _MelloN_

I think we're discussing different issues? When I was saying identifier, I
meant "application index". Agreed that a UUID and "interface index" needs to
be supplied (using terminology from your original message).

- Bernie



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 17:53:03 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23866
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 17:53:02 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86LqHi00837;
	Wed, 6 Sep 2000 17:52:17 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86Lq7i01458
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 17:52:07 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <S2PLQS4G>; Wed, 6 Sep 2000 17:51:52 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC0BE@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 client identification...
Date: Wed, 6 Sep 2000 17:51:46 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Well, there's also:

+-------------+-----+----------+-------------+---------------+--------------
----+-
| option code | len | UUID-len | UUID ...    | interface-len | interface-id
... |
+-------------+-----+----------+-------------+---------------+--------------
----+-

     ---------+--------------------+
      app-len | application-id ... |
     ---------+--------------------+

where the interface-len and app-len are from 0 to <n>, inclusive.

Regarding the application-id, the example of www.xyz.com was bad. And,
perhaps the concept is bad. I was thinking of this as more of a
"kind-of-service" that the DHCP server could use to select a specific
"range" of addresses. I guess this is probably not a good use of this
(especially for IPv6 addresses). [And DHCPv6 will likely have other means of
doing this - like user class, etc.]

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Wednesday, September 06, 2000 5:22 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 client identification...



> The only item I still don't fully agree with is the fixed vs
variable-length
> issue. I wasn't saying that I was using a PREFIX. I feel the interface id
> and application id should be SEPARATE from the UUID. Each address
allocation
> has these three values associated with it, but they are separate items not
a
> single byte-string.

I think that they will be sent seperately.   The question is, do we
want to force the server to deal with them seperately.   Also, think
about how options are formed.   Do we want:

+-------------+-----+--------+-------------+-----+------+
| option code | len | prefix | option code | len | UUID |
+-------------+-----+--------+-------------+-----+------+

or:

+-------------+-----+--------+------+
| option code | len | prefix | UUID |
+-------------+-----+--------+------+

I think the second option is pretty desirable, so we should have a
good reason for not doing it.

> There is no disagreement that fixed is easier to deal with. But, I just
hate
> limiting ourselves today for no good reason. Are you certain that no
system
> (such as a server) might not want more than 256 addresses at a time for an
> interface? Sure, it could change the UUID, but we want to get away from
> that.

We could make the application prefix 16 bytes instead of 8...   I
agree that limiting things this way sounds a bit lame.

> Also, if applications are going to be requesting addresses (we're all
> assuming this, aren't we?), might it not be useful for the server to
> potentially be configured to provide a specific address (from a pool) for
a
> particular application? And having that be something like "www.xyz.com" is
> far more useful than having it be 1.

Hm.   Yes, but...   Supporting a fixed association like this cleanly
opens a huge can of worms.   What if you want to move the application
to a different client?   Is there a way to tell the server that {0,
www.xyz.com, UUID1} and {0, www.xyz.com, UUID2} are the same?   How
far do you want to carry this?   I think as an academic point, you're
right, but as a pragmatic point, I don't think we're answering a
common case here, and I think that figuring out how to do this right
is a much harder problem than we should be considering, and not
something that this protocol really needs to address.   The ability to
get more than one IP address?   Sure.   The ability to do fancy
associations?   Not sure.   I think exporting this problem to the
server is too much - if the client wants consistency, it should be
responsible for maintaining it.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 18:01:47 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23989
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 18:01:47 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86Lwoi25830;
	Wed, 6 Sep 2000 17:58:50 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86Lwji14094
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 17:58:46 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-242.ip.theriver.com [206.97.58.242]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id VAA04876 for <dhcp-v6@bucknell.edu>; Tue, 5 Sep 2000 21:05:18 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e86LuYF01975 for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 14:56:36 -0700 (MST)
Message-Id: <200009062156.e86LuYF01975@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Wed, 06 Sep 2000 17:41:46 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC0BD@lespaul.process.com> 
Date: Wed, 06 Sep 2000 14:56:34 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> I think we're discussing different issues? When I was saying identifier, I
> meant "application index". Agreed that a UUID and "interface index" needs to
> be supplied (using terminology from your original message).

Okay, we agree on this, sort of.  I actually spent some time thinking
about how to make this work when I composed my other reply to you, but
I finally decided that there was no way to do it that didn't force
significant complexity on the server.  For something like the ISC DHCP
server, which practically revels in (I hope useful!) complexity, this
is not such a problem, but for something like an Apple Airport base
station, I think it would be.

Basically, if you force the server to treat the application ID as an
additional qualifier, you force it to have a two-stage lookup - first
it looks up the UUID, which returns a data structure that contains all
the information about all the identity associations for that UUID, and
then you do a lookup in that.   I think for a trivial embedded DHCP
server, you really want to just take the identity association as a
whole and do a single lookup on it.   I don't think it's right to
require the additional complexity in this protocol specification.

Note that you are forced to do this because if you don't, you run the
risk of the interface index and optional application index combining
with the UUID to produce something that's no longer unique.   So you
could argue that the DHCP server should just mash them all together
and do a lookup on that, but I think that would be a bad idea.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 18:12:07 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24063
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 18:12:06 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86MBei00424;
	Wed, 6 Sep 2000 18:11:40 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86MBWi03568
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 18:11:32 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-242.ip.theriver.com [206.97.58.242]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id VAA04919 for <dhcp-v6@bucknell.edu>; Tue, 5 Sep 2000 21:18:05 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e86M9LF02027 for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 15:09:21 -0700 (MST)
Message-Id: <200009062209.e86M9LF02027@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Wed, 06 Sep 2000 11:18:54 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC0B0@lespaul.process.com> 
Date: Wed, 06 Sep 2000 15:09:21 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


Hm, I know I already replied to this, but I just reread it, so now I
have more opinions to generously share with you... :'}

> When a client needs to renew one or more addresses, it sends the address
> assignment ID and the list of addresses (which may be 1 to n). It need NOT
> renew all of the addresses at once (since they may each expire at different
> times). Note that a request with the address assignment ID and 0 addresses
> means that the client doesn't know what addresses it has and thus the server
> would send it *ALL* of the addresses it wants to allocate for that client's
> address assignment ID.

This is how DHCPv6 works now, and I think it's too complicated.  I
think that all of the addresses in any given identity association
should be renewed at once.  I think it makes sense that the client
should be able to request a particular address (perhaps stripped of
its prefix), but this should just be advisory, and the server should
send back a renewal of all the addresses associated with that identity
association, not just those the client selected.  Otherwise I think
it's too complicated to implement, and it doesn't really add much
value - why is it useful for the client to renew out of sync?  Why
would the client know what it should renew and what it shouldn't?  It
might make sense for the client to drop the deprecated address once
all the connections on that address have been dropped, but since this
address is deprecated, I don't think there's any contention for it, so
it doesn't actually add any value to allow (and therefore require the
implementation of) this negotiation.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 18:17:31 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24094
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 18:17:30 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86MGxi20863;
	Wed, 6 Sep 2000 18:16:59 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86MGui24627
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 18:16:56 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-242.ip.theriver.com [206.97.58.242]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id VAA04944 for <dhcp-v6@bucknell.edu>; Tue, 5 Sep 2000 21:23:30 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e86MEkF02081 for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 15:14:46 -0700 (MST)
Message-Id: <200009062214.e86MEkF02081@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 client identification... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Wed, 06 Sep 2000 17:51:46 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC0BE@lespaul.process.com> 
Date: Wed, 06 Sep 2000 15:14:46 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> And DHCPv6 will likely have other means of doing this - like user
> class, etc.

Right, this sounds good.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 18:25:01 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24200
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 18:25:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86MOHi26431;
	Wed, 6 Sep 2000 18:24:17 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86MO7i30700
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 18:24:08 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <S2PLQS47>; Wed, 6 Sep 2000 18:23:52 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC0BF@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Wed, 6 Sep 2000 18:23:43 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

>Basically, if you force the server to treat the application ID as an
>additional qualifier, you force it to have a two-stage lookup - first
>it looks up the UUID, which returns a data structure that contains all
>the information about all the identity associations for that UUID, and
>then you do a lookup in that.

I'm not sure we should comment too heavily on how this is implemented
(internet-drafts usually stay away from forcing implementations).

A simple server could simply use the UUID as a hash and then look through
all the entries matching that UUID for the other two ids. Yes, it means it
can't hash over the entire field.

Or, a simple server could hash on/use the byte stream of:
	uuid-len:uuid:fill1:ifid-len:ifid:fill2:appid-len:appid:fill3
where fill1, fill2, and fill3 are filler bytes (0) up to the maximum length
allowed for each of these fields. That way, you always have a unique value
and never any potential for overlap. Sure, it isn't as compact as it could
be but it also doesn't impose any potentially unrealistic restrictions. The
maximum length for each identifier is likely something that we'd want to
specify anyway.

- Bernie


-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Wednesday, September 06, 2000 5:57 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...



> I think we're discussing different issues? When I was saying identifier, I
> meant "application index". Agreed that a UUID and "interface index" needs
to
> be supplied (using terminology from your original message).

Okay, we agree on this, sort of.  I actually spent some time thinking
about how to make this work when I composed my other reply to you, but
I finally decided that there was no way to do it that didn't force
significant complexity on the server.  For something like the ISC DHCP
server, which practically revels in (I hope useful!) complexity, this
is not such a problem, but for something like an Apple Airport base
station, I think it would be.

Basically, if you force the server to treat the application ID as an
additional qualifier, you force it to have a two-stage lookup - first
it looks up the UUID, which returns a data structure that contains all
the information about all the identity associations for that UUID, and
then you do a lookup in that.   I think for a trivial embedded DHCP
server, you really want to just take the identity association as a
whole and do a single lookup on it.   I don't think it's right to
require the additional complexity in this protocol specification.

Note that you are forced to do this because if you don't, you run the
risk of the interface index and optional application index combining
with the UUID to produce something that's no longer unique.   So you
could argue that the DHCP server should just mash them all together
and do a lookup on that, but I think that would be a bad idea.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 18:34:36 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24322
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 18:34:36 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86MVhi10398;
	Wed, 6 Sep 2000 18:31:43 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86MVfi13981
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 18:31:41 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <S2PLQSVB>; Wed, 6 Sep 2000 18:31:22 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC0C0@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Wed, 6 Sep 2000 18:31:17 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I think this is just a difference of how you treat the data. I don't see why
allowing individual renewals is such a big deal - the DHCP server can find
the addresses either by looking for the requested addres. For renewals, that
seems most efficient for me.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Wednesday, September 06, 2000 6:09 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...



Hm, I know I already replied to this, but I just reread it, so now I
have more opinions to generously share with you... :'}

> When a client needs to renew one or more addresses, it sends the address
> assignment ID and the list of addresses (which may be 1 to n). It need NOT
> renew all of the addresses at once (since they may each expire at
different
> times). Note that a request with the address assignment ID and 0 addresses
> means that the client doesn't know what addresses it has and thus the
server
> would send it *ALL* of the addresses it wants to allocate for that
client's
> address assignment ID.

This is how DHCPv6 works now, and I think it's too complicated.  I
think that all of the addresses in any given identity association
should be renewed at once.  I think it makes sense that the client
should be able to request a particular address (perhaps stripped of
its prefix), but this should just be advisory, and the server should
send back a renewal of all the addresses associated with that identity
association, not just those the client selected.  Otherwise I think
it's too complicated to implement, and it doesn't really add much
value - why is it useful for the client to renew out of sync?  Why
would the client know what it should renew and what it shouldn't?  It
might make sense for the client to drop the deprecated address once
all the connections on that address have been dropped, but since this
address is deprecated, I don't think there's any contention for it, so
it doesn't actually add any value to allow (and therefore require the
implementation of) this negotiation.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 18:44:43 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24381
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 18:44:43 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86Mewi14405;
	Wed, 6 Sep 2000 18:40:58 -0400 (EDT)
Received: from mail.ultradns.com (mail.ultradns.net [64.41.145.150])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86Meli06830
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 18:40:48 -0400 (EDT)
Received: (qmail 11335 invoked from network); 6 Sep 2000 22:40:46 -0000
Received: from nat-external.ultradns.net (HELO ULTRADNS6PMNFK) (216.15.7.195)
  by mail.ultradns.com with SMTP; 6 Sep 2000 22:40:46 -0000
From: "Barr Hibbs" <rbhibbs@ultraDNS.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 Relay Changes
Date: Wed, 6 Sep 2000 15:41:25 -0700
Message-ID: <JCELKJCFMDGAKJCIGGPNEEJCCHAA.rbhibbs@ultraDNS.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEC0BC@lespaul.process.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit


I had only this one work item following the interim DHCPv6 Working Group
meeting on 31 August.  After reviewing the task and the protocol draft, I'm
offering the following wording changes.  I have not proposed a specific
value for the proposed Encapsulated Message Extension, nor for the new
Relayed message type, believing that such details follow, almost
mechanically, once the principles are agreed.

The many other sections which mention or discuss Relay behavior could remain
untouched, as I believe the sections I'm offering below are the crucial
ones.

Please have a lively discussion about this, and reword or rework as you see
fit -- I'm going to be on vacation beginning tomorrow until the 24th,
sampling the food and wine of the Champagne and Burgundy regions of France,
all without my laptop!

--Barr Hibbs
  UltraDNS Corporation



"Relay agents should simply encapsulate the clilent message
in a DHCPv6 Extension;  the relay message should have its
own type."


Internet Draft           DHCP for IPv6           5 May 2000

8.3.  What if the client and server(s) are on different
      links?

      Use of DHCP in such environments requires one or more
      DHCP relays be set up on the client's link, because a
      client may only have a link-local address.  Relays pick
      up the Solicit and Request messages from the client and
      forward them to some set of servers within the DHCP
|     domain, after encapsulating the entire received Solicit
|     or Request message in an extension (number to be
|     determined) -- the Relay then forwards the encapsulated
|     message on towards its destination as a new message of
|     type Relay (number to be determined).

|     Upon receipt of a relayed message, the client looks in
|     the extension for the complete, original message, and
|     acts upon it appropriately.  Replies to relayed
|     messages are first constructed as if they were being
|     sent directly to the originating server, then
|     encapsulated in an extension and sent to the Relay from
|     which the message was received.

      In the case where multiple Relays are in the path
      between client and server, each Relay encapsulates
      messages to forward, so that multiple layers of nesting
      are possibly where multiple Relays are traversed.

      A relay will include one of its own addresses (of
      sufficient scope) of the interface on the same link as
      the client. The relay also includes the subnet prefix
      length of that address in the client's messages.
      Servers receiving the forwarded traffic use this
      information to aid in selecting configuration
      parameters appropriate to the client's link.  The
      servers also use the relay's address as the destination
      to forward client-destined messages for final delivery
      by the relay.  Relays forward client messages to
      servers using some combination of the FF05::1:3(All
      Servers) site-local multicast address, some other
      (perhaps a combination) of site-local multicast
      addresses set up within the DHCP domain to include the
      servers in that domain, or a list of unicast addresses
      for servers.  The network administrator makes relay
      configuration decisions based upon the topological
      requirements (scope) of the DHCP domain they are
      managing.  Note that if the DHCP domain spans more than
      the site-local scope, then the relays MUST be
      configured with global addresses for the client's link
      so as to be reachable by servers outside the relays'
      site-local environment.


10.4. Relay Behavior

      For this discussion, the Relay is assumed to have been
      configured with some list of server destination
      addresses, which may be unicast, the FF05::1:3 (All
      DHCP Servers) multicast address, or some other
      multicast address selected by the network
      administrator.

10.4.1. Relaying of Solicit messages

      When a Relay receives a valid Solicit message, it
|     first encapsulates the entire received Solicit
|     message in a new Extension (number to be
|     determined), then the Relay
|     places the IP address of the interface upon which it
|     received the Solicit message in the ``relay-address''
|     field of the new (outer) message which
|     encapsulates the Solicit. The Relay also places the
      number of bits of that make up the subnet prefix for
      this address in the ``prefix-len'' field of the
|     encapsulating message.

|     The Relay then forwards the encapsulating message to
      the list of server destination addresses that it has
      been configured with.

10.4.2. Relaying of Advertise messages

      When a Relay receives a valid Advertise message, it
      unicasts the message to the link-local address found
      in the ``client's link-local address'' field by way of
      the appropriate network interface.

|     The Relay need not encapsulate the Advertise message.


11.5. Relay Behavior

11.5.1. Relaying of Request or Release messages

      When a Relay receives a valid Request or Release
      message, it forwards it to the IP address found in the
      ``server-address'' field of the message.

|     The Relay encapsulates the received message in an Extension
|     (number to be determined) and forwards the new message.



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 18:50:12 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24433
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 18:50:12 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86Mmsi28049;
	Wed, 6 Sep 2000 18:48:59 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86Mmni06471
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 18:48:49 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-242.ip.theriver.com [206.97.58.242]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id VAA05058 for <dhcp-v6@bucknell.edu>; Tue, 5 Sep 2000 21:55:23 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e86MkbF02182 for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 15:46:37 -0700 (MST)
Message-Id: <200009062246.e86MkbF02182@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Wed, 06 Sep 2000 18:23:43 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC0BF@lespaul.process.com> 
Date: Wed, 06 Sep 2000 15:46:36 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Or, a simple server could hash on/use the byte stream of:
> 	uuid-len:uuid:fill1:ifid-len:ifid:fill2:appid-len:appid:fill3

Right, you could have a complicated way of solving the problem.  Of
course, a representation like this would waste a lot of memory.  The
question is, why do you want the complicated solution - what does it
buy us?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 18:53:44 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24460
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 18:53:44 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e86MrLi28867;
	Wed, 6 Sep 2000 18:53:21 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e86Mr5i32695
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 18:53:06 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-242.ip.theriver.com [206.97.58.242]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id VAA05066 for <dhcp-v6@bucknell.edu>; Tue, 5 Sep 2000 21:59:33 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e86MokF02195 for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 15:50:46 -0700 (MST)
Message-Id: <200009062250.e86MokF02195@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Wed, 06 Sep 2000 18:31:17 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC0C0@lespaul.process.com> 
Date: Wed, 06 Sep 2000 15:50:46 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> I think this is just a difference of how you treat the data. I don't see why
> allowing individual renewals is such a big deal - the DHCP server can find
> the addresses either by looking for the requested addres. For renewals, that
> seems most efficient for me.

If you provide a mechanism for allowing the client to renew individual
portions of the set of addresses provided for an identity association,
it complicates both the specification and the implementation.  The
server has to implement the case where it returns all the addresses
for an identity association.  Now you want to have a special case
where it returns some subset of that.  Why?  What does this buy us?
When are you going to have expiry times that vary in this way?

I would expect that the only time you'd give addresses different
expiry times would be when one or more addresses are deprecated -
those might expire early.  But you can't renew them - when they
expire, that's it - you're done with them.  So providing a mechanism
like this doesn't make any sense to me.  Can you come up with a
practical reason why we would want such a mechanism?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 21:20:10 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25659
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 21:20:10 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e871EZi27589;
	Wed, 6 Sep 2000 21:14:35 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e871EUi21185
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 21:14:30 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <S2PLQSXJ>; Wed, 6 Sep 2000 21:14:14 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC0C2@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Wed, 6 Sep 2000 21:14:07 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted:

Let's step back a moment. I've been thinking in IPv4 terms when DHCPv6 is
really dealing with IPv6 terms.

Addresses have lifetimes, not lease times. Lifetimes are 32-bit values, in
seconds. They actually have two lifetimes - valid and preferred.

In IPv6 Router Advertisements, each prefix has a lifetime (RFC 2461, 4.6.2.
Prefix Information).

Therefore, why would not each address have a lifetime? And, this lifetime
could easily be different.

Also, a case in point (from the DHCPv6 Extensions draft):
         To perform renumbering, the server will include two IP address
         extensions, one to reduce the preferred and valid lifetimes
         for the old address, and another to give the client its new
         address.

Looking into the IPv6 documents brings up some interesting issues:
- How do the DHCPv6 lifetimes interact with the Router Advertisements
lifetimes? Routers will likely be advertising these prefixes with the 'A'
bit clear. I think the DHCPv6 draft should provide some guidelines for
clients.
- Is a multicast RECONFIGURE request really required? The Router
Advertisements might do the job as they would "deprecate" the address and
force clients to renew (if they must honor Router Advertisements).
[Jim/Mike/Charlie - Sorry if you've already addressed these issues in the
DHCPv6 drafts, but I was unable to find the sections.]

I'd suggest that clients honor Router Advertisements and use the lesser of
Router Advertisement and DHCPv6 lifetimes. But this likely requires some
integration between the DHCPv6 client and the IPv6 stack (client needs to be
passed and parse Router Advertisements or some signalling mechanism). [Sorry
for adding complexity.]

- Bernie Volz


-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Wednesday, September 06, 2000 6:51 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...



> I think this is just a difference of how you treat the data. I don't see
why
> allowing individual renewals is such a big deal - the DHCP server can find
> the addresses either by looking for the requested addres. For renewals,
that
> seems most efficient for me.

If you provide a mechanism for allowing the client to renew individual
portions of the set of addresses provided for an identity association,
it complicates both the specification and the implementation.  The
server has to implement the case where it returns all the addresses
for an identity association.  Now you want to have a special case
where it returns some subset of that.  Why?  What does this buy us?
When are you going to have expiry times that vary in this way?

I would expect that the only time you'd give addresses different
expiry times would be when one or more addresses are deprecated -
those might expire early.  But you can't renew them - when they
expire, that's it - you're done with them.  So providing a mechanism
like this doesn't make any sense to me.  Can you come up with a
practical reason why we would want such a mechanism?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep  6 21:30:56 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25746
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 6 Sep 2000 21:30:47 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e871TRi29480;
	Wed, 6 Sep 2000 21:29:27 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e871TAi02222
	for <dhcp-v6@bucknell.edu>; Wed, 6 Sep 2000 21:29:10 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <S2PLQSXR>; Wed, 6 Sep 2000 21:28:54 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC0C3@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 Relay Changes
Date: Wed, 6 Sep 2000 21:28:46 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Barr:

While I understand the forward (client to relay to server) message traffic,
the reverse traffic isn't clear. I assume the server sends back the message
to the relay without having to encapsulate it?

If you allow the multiple encapsulations (one for each relay), how does the
reverse traffic occur? It goes to the relay nearest the client since it is
the only one that can communicate with the client? Why then include
information about the other relays along the forward (to server) path (I
guess this in case of IPsec? But why re-encapsulate?).

Perhaps I missed something in the write up? Please see two comments
(prefixed by >>>) in the original message below.


Have a good time on your vacation.

- Bernie

-----Original Message-----
From: Barr Hibbs [mailto:rbhibbs@ultraDNS.com]
Sent: Wednesday, September 06, 2000 6:41 PM
To: DHCPv6 discussion list
Subject: RE: DHCPv6 Relay Changes



I had only this one work item following the interim DHCPv6 Working Group
meeting on 31 August.  After reviewing the task and the protocol draft, I'm
offering the following wording changes.  I have not proposed a specific
value for the proposed Encapsulated Message Extension, nor for the new
Relayed message type, believing that such details follow, almost
mechanically, once the principles are agreed.

The many other sections which mention or discuss Relay behavior could remain
untouched, as I believe the sections I'm offering below are the crucial
ones.

Please have a lively discussion about this, and reword or rework as you see
fit -- I'm going to be on vacation beginning tomorrow until the 24th,
sampling the food and wine of the Champagne and Burgundy regions of France,
all without my laptop!

--Barr Hibbs
  UltraDNS Corporation



"Relay agents should simply encapsulate the clilent message
in a DHCPv6 Extension;  the relay message should have its
own type."


Internet Draft           DHCP for IPv6           5 May 2000

8.3.  What if the client and server(s) are on different
      links?

      Use of DHCP in such environments requires one or more
      DHCP relays be set up on the client's link, because a
      client may only have a link-local address.  Relays pick
      up the Solicit and Request messages from the client and
      forward them to some set of servers within the DHCP
|     domain, after encapsulating the entire received Solicit
|     or Request message in an extension (number to be
|     determined) -- the Relay then forwards the encapsulated
|     message on towards its destination as a new message of
|     type Relay (number to be determined).

|     Upon receipt of a relayed message, the client looks in
>>> Isn't "client" in the above line "server"?
|     the extension for the complete, original message, and
|     acts upon it appropriately.  Replies to relayed
|     messages are first constructed as if they were being
|     sent directly to the originating server, then
>>> Isn't "server" in the above line "client"? (servers don't originate
messages)
|     encapsulated in an extension and sent to the Relay from
|     which the message was received.

      In the case where multiple Relays are in the path
      between client and server, each Relay encapsulates
      messages to forward, so that multiple layers of nesting
      are possibly where multiple Relays are traversed.

      A relay will include one of its own addresses (of
      sufficient scope) of the interface on the same link as
      the client. The relay also includes the subnet prefix
      length of that address in the client's messages.
      Servers receiving the forwarded traffic use this
      information to aid in selecting configuration
      parameters appropriate to the client's link.  The
      servers also use the relay's address as the destination
      to forward client-destined messages for final delivery
      by the relay.  Relays forward client messages to
      servers using some combination of the FF05::1:3(All
      Servers) site-local multicast address, some other
      (perhaps a combination) of site-local multicast
      addresses set up within the DHCP domain to include the
      servers in that domain, or a list of unicast addresses
      for servers.  The network administrator makes relay
      configuration decisions based upon the topological
      requirements (scope) of the DHCP domain they are
      managing.  Note that if the DHCP domain spans more than
      the site-local scope, then the relays MUST be
      configured with global addresses for the client's link
      so as to be reachable by servers outside the relays'
      site-local environment.


10.4. Relay Behavior

      For this discussion, the Relay is assumed to have been
      configured with some list of server destination
      addresses, which may be unicast, the FF05::1:3 (All
      DHCP Servers) multicast address, or some other
      multicast address selected by the network
      administrator.

10.4.1. Relaying of Solicit messages

      When a Relay receives a valid Solicit message, it
|     first encapsulates the entire received Solicit
|     message in a new Extension (number to be
|     determined), then the Relay
|     places the IP address of the interface upon which it
|     received the Solicit message in the ``relay-address''
|     field of the new (outer) message which
|     encapsulates the Solicit. The Relay also places the
      number of bits of that make up the subnet prefix for
      this address in the ``prefix-len'' field of the
|     encapsulating message.

|     The Relay then forwards the encapsulating message to
      the list of server destination addresses that it has
      been configured with.

10.4.2. Relaying of Advertise messages

      When a Relay receives a valid Advertise message, it
      unicasts the message to the link-local address found
      in the ``client's link-local address'' field by way of
      the appropriate network interface.

|     The Relay need not encapsulate the Advertise message.


11.5. Relay Behavior

11.5.1. Relaying of Request or Release messages

      When a Relay receives a valid Request or Release
      message, it forwards it to the IP address found in the
      ``server-address'' field of the message.

|     The Relay encapsulates the received message in an Extension
|     (number to be determined) and forwards the new message.



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 00:38:02 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29726
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 00:38:02 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e874Z8i06085;
	Thu, 7 Sep 2000 00:35:08 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e874Z2i14091
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 00:35:02 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id EF5F14824; Thu,  7 Sep 2000 00:34:42 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id C0ED74953
	for <dhcp-v6@bucknell.edu>; Thu,  7 Sep 2000 00:34:42 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id AAA0000736898; Thu, 7 Sep 2000 00:33:52 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009070433.AAA0000736898@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion Item - Using DHCPv4 options in DHCPv6 (Item 6 on Confe rence Call Agenda) 
In-reply-to: Your message of "Fri, 01 Sep 2000 09:40:45 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC08D@lespaul.process.com> 
Date: Thu, 07 Sep 2000 00:33:51 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hi Bernie,

I think this is a good idea.  As a note we did go thru the dhcpv4
options (not the latest ones) and tried to copy them to dhcpv6 exts
draft.  I strongly agree that it will be much easier for us in the
future to look at options this way too.

regards,
/jim,



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 00:57:32 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29795
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 00:57:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e874uwi24321;
	Thu, 7 Sep 2000 00:56:58 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e874uii20739
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 00:56:44 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id AFA0D4969; Thu,  7 Sep 2000 00:56:28 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id 6D6A74B16
	for <dhcp-v6@bucknell.edu>; Thu,  7 Sep 2000 00:56:28 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id AAA0000739886; Thu, 7 Sep 2000 00:56:26 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009070456.AAA0000739886@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Co nference Call Agenda) 
In-reply-to: Your message of "Fri, 01 Sep 2000 09:51:55 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC08E@lespaul.process.com> 
Date: Thu, 07 Sep 2000 00:56:25 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Bernie,

>During the DHCPv6 conference call on Thursday, August 31st, I was assigned
>the "responsibility" of coming to a resolution on reconfiguration in DHCPv6
>(items 8, 9, and 18 on Ralph's compiled list):

>8. Allow Reconfigure and Reconfigure-reply messages to be sent via a
>    relay to client's which do not have such reachable IP addresses, in
>    order to inform them of changes in non-releasable resources?  The
>    same thing could also go for Reconfigure-init to some extent.

Not a problem for reconfigure-init either.

But more important question.  

#1 Did the reconfigurexxxx come initially from the server?  
#2 Or can the relay send this without any prodding by the server?

I think net admins I know running DHCPv4 would not be happy having to
manage relays to do reconfigures at all.  So I question #2 is useful to
the market.

Also for #2 the server has no way of identifying the trans ID for 
reconfigure to know a client responded and we don't want the relay doing
this as then it must keep state.

>9. Might a client send a Solicit in response to a Reconfigure-init?
>    What if the topology changes such that this is necessary in order
>    find a DHCP server with can allocate addresses on the new subnet?

As long as the client uses the reconfigure trans-id from the reconfigure
init.  But if the client has a globally reachable address (or of
sufficient scope) this is uncessary as I see it.  

Can you expound on why allocating a new subnet?  I would not think the
server reconfigure-init should reach the client if it could not do this?

>18. Simplify reconfiguration; Use DHCPv4-style reconfiguration

Why is DHCPv4-Style more simple?  Can you expound on what the changes
would be for the list from what is done in DHCPv6 at this point to how
it would look as dhcpv4 does it?  

For example I think we need the archtype of reconfigure and
reconfigure-init as a architectural model.  reconfigure for mobile nodes
as optimization and reconfigure-init for general purpose which is
similar to dhcpv4 reconfigure option.

>I believe the general consensus was a desire to use the DHCPv4-style
>reconfiguration (unicast from server to client). However, there is also a
>desire to accommondate multicasting as for major network reconfiguration
>events, unicasting may inefficient (if there are 1000's of clients to
>notify). But multicasting opens up significant security issues.

We cannot not assume multicast for reconfigure in IPv6.  We may want
health warnings.  But I need to hear on the list what does this all mean
from your perspective comparing the two so we can have that discussion
to reach resolution.

>Let's start the discussion. As we did not set a deadline at the conference
>call, other than stating a week, and given the Labor Day holiday, I'd like
>to conclude this discussion by end of day Friday, September 8.

I don't think that will happen we have to have some discussion on this
one.

thanks
/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 01:22:23 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01914
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 01:22:23 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e875J5i25406;
	Thu, 7 Sep 2000 01:19:05 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e875Iqi19420
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 01:18:52 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id BDBC958DE; Thu,  7 Sep 2000 01:17:59 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id 0F46222E9
	for <dhcp-v6@bucknell.edu>; Thu,  7 Sep 2000 01:17:59 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id BAA0000743709; Thu, 7 Sep 2000 01:17:56 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009070517.BAA0000743709@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Wed, 06 Sep 2000 00:29:41 PDT."
             <200009060729.e867TfC01827@grosse.bisbee.fugue.com> 
Date: Thu, 07 Sep 2000 01:17:55 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted,

>If the client wants to have IP addresses that have different meanings,
>it generates more than one identity.  That is, if the client wants to
>be able to listen on one IP address and provide service for
>www.arf.org, and on another IP address and provide service for
>www.blaznorf.edu, it creates two seperate identities, and it maintains
>completely seperate state machines for two seperate identity
>associations.  The server doesn't need to know that the two identities
>are related, although we may want to make it *possible* for the server
>to know that they are related.

It is imperative IMO that we make it so the server can know that a
client "set" of identities applies to a client interface on the link.
The reason is an implementation one.  I want to be able to reduce my
search tree for clients on the same link and interface for admin reasons
too.

Soooo.. I think part of the client identifier should include a set of
bits that identify the interface too.  Right now the identifier is a
link-local address and 128bits.  I am sure we can do this in 64bits but
I don't trust 32bits.  But that is details.  What I would like is to
have a "set" part in the identifier.

I also think this can reduce the state machine complexity at the client
implementation.  A client identity for the same interfaces if known will
make the code base for IPv6 base reqs much easier to be managed and
perform better.

>There is also the question of when the client can ask for addresses.
>I think the answer is "anytime".  It should be possible to fork a new
>identity association at the request of an application, and to get rid
>of it later at the request of the application.   It should be possible
>for the DHCP client to generate an identity association for each
>network interface at boot time.   I don't think we need to specify
>this, other than to say "the client gets to decide when it does this."

Just a nit.  It don't have to be a fork could be an asynch op or thread.
The input to the client dhcpv6 mod will have to apply to an interface
though as more reason to make a set within the identifier.

>As to the question of synchronization between identity associations, I
>don't think it's possible, although it's a seductive idea.  I think
>the DHCP client should send seperate packets for each identity
>association.  We could make it optionally possible to combine requests
>on behalf of more than one identity association, but I think this
>costs us some complexity and I can't see any way that it helps us,
>beyond perhaps the initial packet requesting addresses for each
>identity association.   It would be nice if the DHCP server could
>present a uniform set of extensions that is consistent across identity
>associations, but I don't see any way to specify this that is helpful
>- I think this is a topic for future research.

I think if we add a set section of bits we can head in the right
direction.

>One interesting fallout from having a renewal time on the identity
>association rather than on the address is that it means that the
>server can respond with zero IP addresses and a renewal time, forcing
>the client to wait some period of time without getting an IP address,
>and then try again.   I don't know if we care about this - it's just
>something that occurred to me.   We have talked about similar
>functionality for DHCPv4 in the past, but I don't get the impression
>that everybody thinks this is a good idea.

I think its a fine idea as long as the adherence to the reqs for Ipv6
addresses in stateless addrconf applies to dhcpv6 too.  

One of the implementation reqs for dhcpv6 is to not break the if6_net
(new ifnet for IPv6) on an IPv6 implementation.  But I don't think it
matters if we renew valid and preferred lifetimes (this is far different
than dhcpv4 nomenclature too and we have to use it) for the addresses a
client identifier.

I also think with the set bits above we could kill all addresses still
on an interface on a link too.  Net admins will not want to send out 3
messages to 3 different identitity associations to stop address use on a
client that has an interface it want to kill.

>So I have two questions: first, does this presentation make sense, or
>have I left out things that are obvious to me but not to the reader.
>Second, if it makes sense, is it the right thing to do?   What do we
>need to change?

I would like to explore during the design of the identifier the ability
to clump if you will a set of bits in the identifiers that make it known
that its from the same client interface.

But I do like this model.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 01:34:59 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03509
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 01:34:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e875YOi30224;
	Thu, 7 Sep 2000 01:34:24 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e875YMi22059
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 01:34:22 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 7F4762595; Thu,  7 Sep 2000 00:34:06 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id C756D1342
	for <dhcp-v6@bucknell.edu>; Thu,  7 Sep 2000 00:34:05 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id BAA0000747748; Thu, 7 Sep 2000 01:34:02 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009070534.BAA0000747748@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 client identification... 
In-reply-to: Your message of "Wed, 06 Sep 2000 00:44:39 PDT."
             <200009060744.e867idC01841@grosse.bisbee.fugue.com> 
Date: Thu, 07 Sep 2000 01:33:57 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted,

>We had a nice discussion about client identifiers during the
>conference call.  The issues that I remember us talking about are:

>	(a) Giving a DHCP client a unique identification that does
>	    not change when network hardware changes
>	(b) Providing a way to identify more than one instance of
>	    usage (I called these identity associations in my message
>	    about the DHCPv6 address model) within an individual client.
>	(c) Providing a way for the server to tell that two identity
>	    associations actually represent one client.

I would add and an interface on the client.

>	(d) Providing a way to have a single authentication
>	    key work with all of a client's identity associations.

I think this is mandatory.

>For (a), we seem to have pretty much agreed that we need a
>universally-unique identifier, similar to what Intel has done in the
>PXE specification.

I would also look at what infiniband has done for the GUID.
I also think we cannot be stingy with the bits here.
If we need 128bits so be it if we can use less fine.

>We can solve (b) by having the client come up with more than one
>UUID.   However, to solve (c) and (d), it would be better if we
>defined a way to have the DHCP client specify a UUID and then specify
>a modifier to that UUID, so that the identity association would
>actually be made up of {modifier, UUID}.   Authentication would be
>done based on {UUID}, not on {modifier, UUID}, and the server could
>therefore tell that two identity associations are the same client by
>noticing that although the modifier is different, the UUID is the
>same.

This will work I think.

>In order to avoid creating the possibility of namespace clashes, I'd
>suggest that we specify the modifier as a 16-bit number, defined by
>the client, that's just an index.   So if a DHCP client had two
>network interfaces, its two identity associations would probably be
>{0, UUID} and {1, UUID}.

I would like to see the UUID be recognizable if its the same client for
the same interface.  So I guess I want to discuss what we do with the
UUID?  This may be where the infiniband GUID helps.

>There is one problem with this: if the DHCP client is not consistent
>about assigning prefixes, it would be possible for it to assign {0,
>UUID} to one network interface one time, and {1, UUID} to that network
>interface the next time.   This shouldn't be a huge problem for a
>typical client, but for fancy clients the client implementor might
>want to actually maintain its own mapping between the network hardware
>address and the index.

Do you mean "prefixes" above for the UUID?

>It might also make sense to have the modifier be an 8-bit interface
>index and an 8-bit application index, with application index == 0
>always being the initial configuration for that interface.   So a
>typical client with two network interfaces would have these two
>identity associations: {0, 0, UUID} and {1, 0, UUID}.   And if an
>application decided to listen with its own address on each interface,
>then the client would have four identity associations: {0, 0, UUID},
>{0, 1, UUID}, {1, 0, UUID} and {1, 1, UUID}.

I would use more than 8 bits for each.  I would use 16 for each and 96
for the UUID.

The success or failure of this is how we do the UUID or whatever it ends
up to be.  

I think that needs its own mail thread discussion to get some ideas.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 02:00:10 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06439
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 02:00:09 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e875uqi14284;
	Thu, 7 Sep 2000 01:56:52 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e875uji30394
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 01:56:45 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 5C35211D1; Thu,  7 Sep 2000 01:56:30 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id 223661340
	for <dhcp-v6@bucknell.edu>; Thu,  7 Sep 2000 01:56:30 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id BAA0000750393; Thu, 7 Sep 2000 01:55:39 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009070555.BAA0000750393@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Wed, 06 Sep 2000 13:33:11 PDT."
             <200009062033.e86KXBF01749@grosse.bisbee.fugue.com> 
Date: Thu, 07 Sep 2000 01:55:38 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted,

>Do we need to make an explicit distinction here between "new" and
>"renew"?

This I think must be an idempotent semantic to the server and how it is
in dhcpv6 since we removed the xid stuff.  The client should not have to
do anything special or understand this with your proposed model.  An
identity association will only ever get x number of addresses for a
specific instance of the UUID with the modifiers:

  Interface           Instance            Identifier
    1                   1                  glok-glok-clump
    1                   2                  glok-glok-clump
    2                   1                  glok-glok-clump

Interface 1 Instance 1 will get x addresses
Interface 1 Instance 2 will get x addresses (client wanted more addresses for
                                 another URL like your example in
                                 your kick-off thread on this topic)

[I don't like zero to represent interfaces or instances also I liked
your three-tuple approach to identification and I think Bernie did to as
his respond had 3-tuple also]

Once the server gives Interface 1 Instance 1 a set of addresses and the 
client comes back its either asking for a renewal or releasing them.

This also I think addresses Ralphs concern about the multiple address
model being different than DHCPv4.  We keep the good implementation
knowledge of a finite set address model from DHCPv4, but permit with the
Interface+Instance+UUID model the ability to do what Charlie wants with
minimal work to the spec and I think a much clearer implementation
model.  As captain kirk stated we would have a win-win scenario and we
can declare victory as a WG and move on.

If we can also define this UUID beast.

p.s. Also you should re-suggest your clump idea to send these addresses
back and forth at the appropriate time you hinted at in the design team.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 02:04:21 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12310
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 02:04:19 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8763ji28257;
	Thu, 7 Sep 2000 02:03:45 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8763ci06740
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 02:03:38 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 10C9B11C7; Thu,  7 Sep 2000 02:03:23 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id CD63A103D
	for <dhcp-v6@bucknell.edu>; Thu,  7 Sep 2000 02:03:22 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id CAA0000751978; Thu, 7 Sep 2000 02:03:19 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009070603.CAA0000751978@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Wed, 06 Sep 2000 16:46:22 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC0BC@lespaul.process.com> 
Date: Thu, 07 Sep 2000 02:03:18 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Bernie,

>>Jim asked us to contribute actual verbiage for any
>>changes we want to the current spec, so I'm expecting to contribute
>>verbiage for the address model proposal, but I don't feel confident
>>that I could word this part correctly.   Could you do that?
>
>Hm. I'm using my IPv6 knowledge that's several years old. From what I
>understand, it is hopefully still valid. I can certainly try, but there may
>be little need as this concept (requesting an address with a specific
>prefix) is already in the DHCPv6 draft.

We need to recall that we today permit two ways to give out addresses.
In dhcpv6 of course.

#1.  Send the client 128bit address in total.
#2.  Send the client prefixes and they use their link-local.
     (this is how stateless works).

This is not a problem to write up if we understand our own model it will
work both ways above again I assume.

>>I'm afraid I don't know what you mean by a "basic" address request.
>>Can you expand on this?

>Sure. What I meant was the request the system generates when it comes up,
>instead of an application or otherwise requested allocation. All systems are
>likely to request this whenever DHCP is enabled on an interface, so rather
>than having them supply an identifier, make this the no (or null)
>identifier. That way, a simple client that only supports "one" allocation
>never has to deal with this identifier.

I don't think a null identifier is wise.  Recall one of the goals.
These need to be used for security.  I think the IESG will barf all over
any identifiers that also are used to determine security associations
and then we permit it to be null.  At least I would if on the IESG.

If we go with teds model I don't see any overhead using the identifier
and their is minimal performance gain vs the functionality we get by
saying you must use the identifier.  We have an opportunity with this
model to also make dhcpv6 very "secure" ""in a cost efficienct manner".

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 02:10:23 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12696
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 02:10:23 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8769mi11780;
	Thu, 7 Sep 2000 02:09:48 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8769ki28612
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 02:09:46 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 41B58E5B; Thu,  7 Sep 2000 02:09:31 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id 1F2C81DE
	for <dhcp-v6@bucknell.edu>; Thu,  7 Sep 2000 02:09:31 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id CAA0000752627; Thu, 7 Sep 2000 02:08:48 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009070608.CAA0000752627@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 client identification... 
In-reply-to: Your message of "Wed, 06 Sep 2000 14:21:57 PDT."
             <200009062121.e86LLvF01856@grosse.bisbee.fugue.com> 
Date: Thu, 07 Sep 2000 02:08:42 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted,

>+-------------+-----+--------+-------------+-----+------+
>| option code | len | prefix | option code | len | UUID |
>+-------------+-----+--------+-------------+-----+------+
>
>or:
>
>+-------------+-----+--------+------+
>| option code | len | prefix | UUID |
>+-------------+-----+--------+------+
>
>I think the second option is pretty desirable, so we should have a
>good reason for not doing it.

Absolutely correct.  As side note I was one of the key principles in
IPv6 that shot variable addresses in the head and had some formiddable
opponents.  I am pretty adamant about this the second case is much less
code all around too.

Also I had suggested in earlier response use 
  16bits for interface
  16bits for instance

thats 32K of interfaces and 32k of instances.  something else in dhcpv6
will break before that does.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 02:17:11 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12754
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 02:17:10 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e876Gci02738;
	Thu, 7 Sep 2000 02:16:38 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e876GUi25181
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 02:16:30 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 5CA3927BE; Thu,  7 Sep 2000 01:16:15 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id DF7BC1350
	for <dhcp-v6@bucknell.edu>; Thu,  7 Sep 2000 01:16:14 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id CAA0000753948; Thu, 7 Sep 2000 02:16:12 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009070616.CAA0000753948@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Wed, 06 Sep 2000 14:56:34 PDT."
             <200009062156.e86LuYF01975@grosse.bisbee.fugue.com> 
Date: Thu, 07 Sep 2000 02:16:11 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted,

Sorry I am catching up.  Just got back from labor day really.


>Basically, if you force the server to treat the application ID as an
>additional qualifier, you force it to have a two-stage lookup - first
>it looks up the UUID, which returns a data structure that contains all
>the information about all the identity associations for that UUID, and
>then you do a lookup in that.   I think for a trivial embedded DHCP
>server, you really want to just take the identity association as a
>whole and do a single lookup on it.   I don't think it's right to
>require the additional complexity in this protocol specification.

I think we need Instance or Application-index or whatever.  But I don't
think its a problem for a server if the field is split or all in one
chunk.

Interface   App-Index-Instance   UUID

or 

UUID == Interface+App-Index-Instance+client ID

In either case I think

16bits+16bits+96bits is required and sufficient.

When I do the hash, link-list, or btree search I will concatenate them
at the server and do the lookup once (unless I don't get hit right).

Either way your search will be the same.

>Note that you are forced to do this because if you don't, you run the
>risk of the interface index and optional application index combining
>with the UUID to produce something that's no longer unique.   So you
>could argue that the DHCP server should just mash them all together
>>and do a lookup on that, but I think that would be a bad idea.

Superb argument.  Thats right we want the uuid to be alone for the
security too.

They should be split up in the eventual message format.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 02:22:43 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12790
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 02:22:43 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e876MDi19867;
	Thu, 7 Sep 2000 02:22:13 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e876M9i22963
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 02:22:09 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id F0AEF1294; Thu,  7 Sep 2000 01:21:53 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 7F5191CE2
	for <dhcp-v6@bucknell.edu>; Thu,  7 Sep 2000 01:21:53 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id CAA0000754841; Thu, 7 Sep 2000 02:21:51 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009070621.CAA0000754841@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Wed, 06 Sep 2000 15:09:21 PDT."
             <200009062209.e86M9LF02027@grosse.bisbee.fugue.com> 
Date: Thu, 07 Sep 2000 02:21:50 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted,

>This is how DHCPv6 works now, and I think it's too complicated.  I
>think that all of the addresses in any given identity association
>should be renewed at once.  I think it makes sense that the client
>should be able to request a particular address (perhaps stripped of
>its prefix), but this should just be advisory, and the server should
>send back a renewal of all the addresses associated with that identity
>association, not just those the client selected.  Otherwise I think
>it's too complicated to implement, and it doesn't really add much
>value - why is it useful for the client to renew out of sync?  Why
>would the client know what it should renew and what it shouldn't?  It
>might make sense for the client to drop the deprecated address once
>all the connections on that address have been dropped, but since this
>address is deprecated, I don't think there's any contention for it, so
>it doesn't actually add any value to allow (and therefore require the
>implementation of) this negotiation.

Also why would a server give one valid / preferred time to one
address and not the other?  I can see it happening but why?

But then lets suppose an admin says this client gets three addresses for
this Interface+Instance+UUID.  But one of them I want to renew with me
cause the prefix is a "special" thing?  Then we do have the situation
where renewing all of them is a waste of client and server processing.

We need to consider this carefully.

But it is still not like dhcpv6.  The difference is that this model has
finite set of addresses for a specific client UUID not variable.
So it is very managable.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 02:55:13 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12962
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 02:55:12 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e876nYi12304;
	Thu, 7 Sep 2000 02:49:34 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e876nKi24126
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 02:49:20 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 03BB4420C; Thu,  7 Sep 2000 01:49:04 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 611B9246D
	for <dhcp-v6@bucknell.edu>; Thu,  7 Sep 2000 01:49:04 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id CAA0000756655; Thu, 7 Sep 2000 02:49:00 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009070649.CAA0000756655@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Wed, 06 Sep 2000 21:14:07 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC0C2@lespaul.process.com> 
Date: Thu, 07 Sep 2000 02:48:58 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Bernie,

>Let's step back a moment. I've been thinking in IPv4 terms when DHCPv6 is
>really dealing with IPv6 terms.

This is an important mind set for dhcpv6.

>Addresses have lifetimes, not lease times. Lifetimes are 32-bit values, in
>seconds. They actually have two lifetimes - valid and preferred.

yes we need to not think in the same lease terms as dhcpv4 but as you
state above I said this in earlier thread.

>In IPv6 Router Advertisements, each prefix has a lifetime (RFC 2461, 4.6.2.
>Prefix Information).

>Therefore, why would not each address have a lifetime? And, this lifetime
>could easily be different.

This was my input to Ted.  In fact IPv6 does encourage admins to give ou
different times for different prefixes.  They may know that the first
prefix to a client who can have 3 addresses will expire before the other
too and reduce the preferred lifetime.

As I said if an admin does this dhcpv6 should not require the entire
addresses set to be renewed because the earlier address has become
deprecated and about to expire.

>Also, a case in point (from the DHCPv6 Extensions draft):
>         To perform renumbering, the server will include two IP address
>         extensions, one to reduce the preferred and valid lifetimes
>         for the old address, and another to give the client its new
>         address.

Also what we wanted to do to support the notion of T1 and T2 in dhcpv4
was state that when your address is 80% till it becomes deprecated (the
preferred timer goes off) renew the address or ask for a new one.

In the model Ted is proposing all the client can do is renew the address
or request a new set.

But in IPv6 it is permissable to have addresses expire at different
times.

>Looking into the IPv6 documents brings up some interesting issues:
>- How do the DHCPv6 lifetimes interact with the Router Advertisements
>lifetimes? Routers will likely be advertising these prefixes with the 'A'
>bit clear. I think the DHCPv6 draft should provide some guidelines for
>clients.

They must coexist.  We have to do duplicate address detection for dhcpv6
addresses just like we do for stateless addresses.  This will prevent
collisions.

Implementor Note - What I would do is put the dhcpv6 addresses on the
same if6_net list that the stateless are on and mark them as dhcpv6
begotten.

>- Is a multicast RECONFIGURE request really required? The Router
>Advertisements might do the job as they would "deprecate" the address and
>force clients to renew (if they must honor Router Advertisements).
>[Jim/Mike/Charlie - Sorry if you've already addressed these issues in the
>DHCPv6 drafts, but I was unable to find the sections.]

Assume the customer is not running stateless or only to tell the clients
go use dhcpv6.  The admin does not want stateless sending out any
prefixes?  

Stateless does not need reconfigure archtype  Router is on the link and
advertisements rule.

>I'd suggest that clients honor Router Advertisements and use the lesser of
>Router Advertisement and DHCPv6 lifetimes. But this likely requires some
>integration between the DHCPv6 client and the IPv6 stack (client needs to be
>passed and parse Router Advertisements or some signalling mechanism). [Sorry
>for adding complexity.]

Yes stateless rules for a prefix.  If a network permits this they should
have good reason.  One good reason would be use dhcpv6 to give out
addresses using prefixes as stateless does but use stateless router
advertisements to force renumbering by reducing valid and preferred
lifetimes for all addresses.  Thats why I will mark the ipv6 addresses
on the if6_net as stateful or stateless.  If Rtr adv reduces lifetimes I
will know this and be able to either release the address or renew it.
Another reason to permit individual renewals because one prefix may get
renumbered and the others are fine.

The bottom line is once you permit a client to have mulitple addresses
for an identifier though finite and fixed they must be individually
renewable and updated per IPv6 architecture and stateless addrconf.

The good news is that stateless or stateful are NOT permitted to send a
zero valid lifetime to kill and address it must be not less than 2
minutes.  This was added to stateless rfc2462.txt to prevent DOS attacks
from shooting IPv6 nodes in the head with rtr advs. 

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 03:02:00 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13076
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 03:01:59 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e87713i21366;
	Thu, 7 Sep 2000 03:01:03 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e87710i26498
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 03:01:00 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id 5D3CB10CC; Thu,  7 Sep 2000 02:00:45 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 474C811EF
	for <dhcp-v6@bucknell.edu>; Thu,  7 Sep 2000 02:00:41 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id CAA0000757316; Thu, 7 Sep 2000 02:59:49 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009070659.CAA0000757316@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 Relay Changes 
In-reply-to: Your message of "Wed, 06 Sep 2000 21:28:46 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC0C3@lespaul.process.com> 
Date: Thu, 07 Sep 2000 02:59:48 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Barr/folks,

Is this really encapsulation? 

or

A new relay extension msg type to encapsulate client solicits and
requests.

At the design meeting I was thinking real encapsulation.

So the entire Ipv6 would be encapsulated by the relay and sent to the
server in the various ways as Barr noted (multicast/unicast).

We would have a new protocol-id for IPv6 that says inside this IPv6
header is a dhcpv6 message proto-id ??? TBD.

The server upon receiving this at the IPv6 net layer would decapsulate
move the relay address into the giaddr or whatever field, then deliver
it via udp to the server.

The server then would respond directly back to the relay as it does now
in dhcpv4 or dhcpv6.  

This model would need no nested encaps or decaps as the routing would
take care of getting the packet to the server from the relay based on
the dst address in IPv6 header.

If one wants to use a new extension to do this then the question is the
clients Ipv6 header kept in tact behind the relay UDP data (where the
new extension will exist)?

But even in that case it is not necessary to nest the extension or the
encap/decap as this is handled by the routing fabric for IPv6.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 11:11:27 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18111
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 11:11:23 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e87F6Ri04278;
	Thu, 7 Sep 2000 11:06:29 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e87F5ri02801
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 11:05:53 -0400 (EDT)
Received: from mjs-pc (mjs-pc.cisco.com [172.27.181.69]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA08398 for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 11:05:36 -0400 (EDT)
Message-Id: <4.2.0.58.20000907102335.0351bb90@funnel.cisco.com>
X-Sender: mjs@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 07 Sep 2000 11:06:13 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Mark Stapp <mjs@cisco.com>
Subject: Re: DHCPv6 client identification... 
In-Reply-To: <200009061901.e86J1HF01433@grosse.bisbee.fugue.com>
References: <Message from Bernie Volz <Volz@ipworks.com>
 <63D30D6E10CFD11190A90000F805FE8602BEC0B6@lespaul.process.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I think Ted uses a really interesting example. I'd like to suggest that 
client implementations MUST maintain a consistent association between the 
binding-id part of the identification and a physical interface as long as 
that interface has a DHCP-assigned address. In Ted's example:

>address, or winds up consuming extra addresses, because the DHCP
>client doesn't maintain a consistent identification for each
>interface.   Consider the following sequence of events:
>
>(1) laptop is powered on with an ethernet card in pcmcia slot 1.
>(2) laptop gets IP address using DHCP for {0, UUID}
>(3) application starts, requests the client to get another identity
>(4) client gets that identity using {1, UUID}
>(5) user inserts 802.11 card, which acquires an identity using {2, UUID}
>(6) user power cycles laptop
>(7) laptop gets IP address for ethernet card using {0, UUID}
>(8) laptop gets IP address for 802.11 card using {1, UUID}
>(9) application starts, gets its IP address using {2, UUID}
>
>Note that the IP addresses assigned to {1, UUID} and {2, UUID} will
>likely be different the second time through.

The client has active bindings for the ethernet and the 802.11 devices, but 
doesn't use the binding-id part of the client-id consistently across 
re-starts. That shouldn't happen: the client should be required to use the 
client-id tuple consistently once it has acquired lease(s) with it. 
Requiring consistent use means that we can just use a single 16- or 32-bit 
binding-id along with the UUID to form the tuple: we don't need to require 
the client to manage 'interface indexes', we just have to require that the 
client use the binding-id consistently during the lifetime of the leases 
associated with it.

The other part of this that's interesting is the 'application-requested' 
address situation. This example raises several very interesting questions. 
What does that application do with the address that it asked for across 
reboots? What do the stack and dhcp client do with the address? When this 
host reboots, its dhcp client and stack find three dhcp client-identities, 
and a set of one or more addresses associated with each of those three. I 
can imagine how the dhcp client handles the two binding sets that are 
associated with the interface cards, and I suppose that it pays attention 
to those leases' expiration times, and renews them pretty much 
indefinitely. Is the stack supposed to know which of the three was 
'application-requested'? Is there some way for the application to determine 
that one of the address sets was allocated by a previous instance of the 
application process? Is the stack supposed to prohibit other processes from 
using the address(es) associated with that application-requested 
allocation? Is the dhcp client supposed to keep renewing those addresses 
indefinitely, even if the application doesn't run before the leases' 
renewal time(s)? What if the application never runs again?

I like the example a lot, but I dislike having to answer all of these 
questions now, in the absence of concrete proposals about the interaction 
between applications and the ipv6 dhcp client. I feel that we're trying to 
imagine a capability from the server-side, a capability that we all seem to 
think will be useful (and possibly inevitable). But the capability is 
fundamentally a client problem, and I don't personally see enough detail to 
know what I would have to do if I were to have to implement a client. We 
should either be extremely restrictive, and require that the dhcp client 
release all application-requested lease bindings upon restart, or we should 
specify that the dhcp client will ignore and not renew any 
application-requested bindings. Either of those choices seems awkward to 
me. Either way, we'd have to require that the dhcp client would distinguish 
application requested bindings from stack- or interface-requested bindings. 
We either need to add a significant work-item to decide how the dhcp client 
should handle this hypothetical application-level capability, or we need to 
decide that we won't chase our tails trying to handle it until it exists.

The client-id mechanism that's been proposed seems flexible enough that it 
can accomodate multiple requests for new bindings from a single host, even 
a host with a single physical interface. That suggests that the protocol 
can handle application-requested bindings whenever they show up, although 
dhcp client behavior will have to be carefully specified.

-- Mark



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 12:04:02 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19673
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 12:03:55 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e87Fxxi16416;
	Thu, 7 Sep 2000 11:59:59 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e87Fxsi04997
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 11:59:54 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <S2PLQTJW>; Thu, 7 Sep 2000 11:59:28 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC0CA@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 client identification...
Date: Thu, 7 Sep 2000 11:59:22 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Mark:

The only problem with the consistent ids across reboots is for clients that
either don't have permanent storage or where the permanent storage has
failed. But, in these cases we really should require the client to first
release any resources it might have had. BTW: This is a reason I personally
don't like the interface id just being a number such as 1, 2, 3. A more
descriptive value means that the mac address or other identifier for the
interface can be used and avoid some of the problems. Agreed that you create
others, such as by swapping out a card for a replacement; in that case the
two are really identical and there is no reason for the client to get
different addresses.

Regarding the application issues, I think part of the application/DHCP API
would be for the application to register continued interest in the address.
One simple way to do this is to maintain a reference count on the address in
the DHCP client that is incremented when an application requests the address
and decremented when it releases it (note that this is an explicit release,
not just it has no open connections - process rundown would need to notify
the DHCP client). Once the reference count is 0, the DHCP client could
either then release the address or just not renew it next time it expires.

Across a reboot, the DHCP client would reset the reference count (and
release the address). For a warm reboot, the application is still running
and therefore the client takes the same steps it does for other addresses to
determine if they are still valid or whether the client has moved to a
different network.

- Bernie

-----Original Message-----
From: Mark Stapp [mailto:mjs@cisco.com]
Sent: Thursday, September 07, 2000 11:06 AM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 client identification...


I think Ted uses a really interesting example. I'd like to suggest that 
client implementations MUST maintain a consistent association between the 
binding-id part of the identification and a physical interface as long as 
that interface has a DHCP-assigned address. In Ted's example:

>address, or winds up consuming extra addresses, because the DHCP
>client doesn't maintain a consistent identification for each
>interface.   Consider the following sequence of events:
>
>(1) laptop is powered on with an ethernet card in pcmcia slot 1.
>(2) laptop gets IP address using DHCP for {0, UUID}
>(3) application starts, requests the client to get another identity
>(4) client gets that identity using {1, UUID}
>(5) user inserts 802.11 card, which acquires an identity using {2, UUID}
>(6) user power cycles laptop
>(7) laptop gets IP address for ethernet card using {0, UUID}
>(8) laptop gets IP address for 802.11 card using {1, UUID}
>(9) application starts, gets its IP address using {2, UUID}
>
>Note that the IP addresses assigned to {1, UUID} and {2, UUID} will
>likely be different the second time through.

The client has active bindings for the ethernet and the 802.11 devices, but 
doesn't use the binding-id part of the client-id consistently across 
re-starts. That shouldn't happen: the client should be required to use the 
client-id tuple consistently once it has acquired lease(s) with it. 
Requiring consistent use means that we can just use a single 16- or 32-bit 
binding-id along with the UUID to form the tuple: we don't need to require 
the client to manage 'interface indexes', we just have to require that the 
client use the binding-id consistently during the lifetime of the leases 
associated with it.

The other part of this that's interesting is the 'application-requested' 
address situation. This example raises several very interesting questions. 
What does that application do with the address that it asked for across 
reboots? What do the stack and dhcp client do with the address? When this 
host reboots, its dhcp client and stack find three dhcp client-identities, 
and a set of one or more addresses associated with each of those three. I 
can imagine how the dhcp client handles the two binding sets that are 
associated with the interface cards, and I suppose that it pays attention 
to those leases' expiration times, and renews them pretty much 
indefinitely. Is the stack supposed to know which of the three was 
'application-requested'? Is there some way for the application to determine 
that one of the address sets was allocated by a previous instance of the 
application process? Is the stack supposed to prohibit other processes from 
using the address(es) associated with that application-requested 
allocation? Is the dhcp client supposed to keep renewing those addresses 
indefinitely, even if the application doesn't run before the leases' 
renewal time(s)? What if the application never runs again?

I like the example a lot, but I dislike having to answer all of these 
questions now, in the absence of concrete proposals about the interaction 
between applications and the ipv6 dhcp client. I feel that we're trying to 
imagine a capability from the server-side, a capability that we all seem to 
think will be useful (and possibly inevitable). But the capability is 
fundamentally a client problem, and I don't personally see enough detail to 
know what I would have to do if I were to have to implement a client. We 
should either be extremely restrictive, and require that the dhcp client 
release all application-requested lease bindings upon restart, or we should 
specify that the dhcp client will ignore and not renew any 
application-requested bindings. Either of those choices seems awkward to 
me. Either way, we'd have to require that the dhcp client would distinguish 
application requested bindings from stack- or interface-requested bindings. 
We either need to add a significant work-item to decide how the dhcp client 
should handle this hypothetical application-level capability, or we need to 
decide that we won't chase our tails trying to handle it until it exists.

The client-id mechanism that's been proposed seems flexible enough that it 
can accomodate multiple requests for new bindings from a single host, even 
a host with a single physical interface. That suggests that the protocol 
can handle application-requested bindings whenever they show up, although 
dhcp client behavior will have to be carefully specified.

-- Mark



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 18:00:15 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28130
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 18:00:10 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e87Luui01974;
	Thu, 7 Sep 2000 17:56:56 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e87Lupi31003
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 17:56:51 -0400 (EDT)
Received: from mjs2-nt (ch2-dhcp133-96.cisco.com [161.44.133.96]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA03909 for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 17:56:35 -0400 (EDT)
Message-Id: <4.2.0.58.20000907123921.01a65dc0@funnel.cisco.com>
X-Sender: mjs@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 07 Sep 2000 17:56:47 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Mark Stapp <mjs@cisco.com>
Subject: RE: DHCPv6 client identification...
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEC0CA@lespaul.process.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Bernie,

I hear you, but I still think that there are two kinds of info that are 
useful, and that both are available. As you noted in one of your earlier 
emails, some kind of link address must be available anyway. I think that 
that doesn't _have_ to be part of the binding identification, though some 
server implementations _might_ use that address to make decisions about 
lease bindings. I'm only trying to suggest that, rather than mandating that 
some physical characteristic be used in addition to the uuid, we only 
mandate the opaque binding-id. As you say, that only poses a problem for 
clients who've lost all of their state. The link address information is 
still available to the server, which may use it as part of its 
internal  implementation, but it doesn't _have_ to.

The common workstation client could simply use binding-id '0' (or '1') to 
refer to its single ethernet interface, and that interface could be changed 
without confusing the server or generating new address bindings. The laptop 
client in Ted's example must maintain enough state along with the leases it 
obtains to use the binding-ids consistently. If the laptop loses its state, 
it may inadvertently swap the relationship between the two interfaces and 
the two binding-ids. I guess I don't see more than two possibilities there:

1) the server doesn't care which interface either set of addresses is 
associated with. That is, the server doesn't distinguish between the two 
link-local addresses. For example, it doesn't detect wireless cards or give 
out different addresses to wireless cards. The server either notices that 
the relationship between links and binding-ids has swapped, decides that it 
cares about that, and swaps ip bindings to match, or it doesn't notice or 
doesn't care and it gives out the existing ip bindings that match the 
binding-ids.

2) the server cares which addresses are associated with each link address. 
The server either clears its existing binding info for the uuid+binding-id 
tuples, and creates new bindings, or it has recorded the previous link 
addresses, notices what has happened, and updates its bindings to reflect 
the new binding-id to interface relationship.

That's why I prefer an arbitrary binding-id. It saves the expense of 
describing how to use some semantically meaningful component, and it avoids 
over-specification of implementations' internal data structures. Some 
implementations will use link addresses, host-names, user-class strings, 
vendor-specific strings, etc. to make decisions, but none of those 
components has to be used in forming the client-id.

I absolutely agree that it would be very handy for clients to set a 'no 
state available' bit in their initial message as an indication that the 
client has no existing state for the uuid+binding-id tuple.

-- Mark

At 11:59 AM 9/7/00 -0400, you wrote:
>Mark:
>
>The only problem with the consistent ids across reboots is for clients that
>either don't have permanent storage or where the permanent storage has
>failed. But, in these cases we really should require the client to first
>release any resources it might have had. BTW: This is a reason I personally
>don't like the interface id just being a number such as 1, 2, 3. A more
>descriptive value means that the mac address or other identifier for the
>interface can be used and avoid some of the problems. Agreed that you create
>others, such as by swapping out a card for a replacement; in that case the
>two are really identical and there is no reason for the client to get
>different addresses.
>
>Regarding the application issues, I think part of the application/DHCP API
>would be for the application to register continued interest in the address.
>One simple way to do this is to maintain a reference count on the address in
>the DHCP client that is incremented when an application requests the address
>and decremented when it releases it (note that this is an explicit release,
>not just it has no open connections - process rundown would need to notify
>the DHCP client). Once the reference count is 0, the DHCP client could
>either then release the address or just not renew it next time it expires.
>
>Across a reboot, the DHCP client would reset the reference count (and
>release the address). For a warm reboot, the application is still running
>and therefore the client takes the same steps it does for other addresses to
>determine if they are still valid or whether the client has moved to a
>different network.
>
>- Bernie
>
>-----Original Message-----
>From: Mark Stapp [mailto:mjs@cisco.com]
>Sent: Thursday, September 07, 2000 11:06 AM
>To: DHCPv6 discussion list
>Subject: Re: DHCPv6 client identification...
>
>
>I think Ted uses a really interesting example. I'd like to suggest that
>client implementations MUST maintain a consistent association between the
>binding-id part of the identification and a physical interface as long as
>that interface has a DHCP-assigned address. In Ted's example:
>
> >address, or winds up consuming extra addresses, because the DHCP
> >client doesn't maintain a consistent identification for each
> >interface.   Consider the following sequence of events:
> >
> >(1) laptop is powered on with an ethernet card in pcmcia slot 1.
> >(2) laptop gets IP address using DHCP for {0, UUID}
> >(3) application starts, requests the client to get another identity
> >(4) client gets that identity using {1, UUID}
> >(5) user inserts 802.11 card, which acquires an identity using {2, UUID}
> >(6) user power cycles laptop
> >(7) laptop gets IP address for ethernet card using {0, UUID}
> >(8) laptop gets IP address for 802.11 card using {1, UUID}
> >(9) application starts, gets its IP address using {2, UUID}
> >
> >Note that the IP addresses assigned to {1, UUID} and {2, UUID} will
> >likely be different the second time through.
>
>The client has active bindings for the ethernet and the 802.11 devices, but
>doesn't use the binding-id part of the client-id consistently across
>re-starts. That shouldn't happen: the client should be required to use the
>client-id tuple consistently once it has acquired lease(s) with it.
>Requiring consistent use means that we can just use a single 16- or 32-bit
>binding-id along with the UUID to form the tuple: we don't need to require
>the client to manage 'interface indexes', we just have to require that the
>client use the binding-id consistently during the lifetime of the leases
>associated with it.
>
>The other part of this that's interesting is the 'application-requested'
>address situation. This example raises several very interesting questions.
>What does that application do with the address that it asked for across
>reboots? What do the stack and dhcp client do with the address? When this
>host reboots, its dhcp client and stack find three dhcp client-identities,
>and a set of one or more addresses associated with each of those three. I
>can imagine how the dhcp client handles the two binding sets that are
>associated with the interface cards, and I suppose that it pays attention
>to those leases' expiration times, and renews them pretty much
>indefinitely. Is the stack supposed to know which of the three was
>'application-requested'? Is there some way for the application to determine
>that one of the address sets was allocated by a previous instance of the
>application process? Is the stack supposed to prohibit other processes from
>using the address(es) associated with that application-requested
>allocation? Is the dhcp client supposed to keep renewing those addresses
>indefinitely, even if the application doesn't run before the leases'
>renewal time(s)? What if the application never runs again?
>
>I like the example a lot, but I dislike having to answer all of these
>questions now, in the absence of concrete proposals about the interaction
>between applications and the ipv6 dhcp client. I feel that we're trying to
>imagine a capability from the server-side, a capability that we all seem to
>think will be useful (and possibly inevitable). But the capability is
>fundamentally a client problem, and I don't personally see enough detail to
>know what I would have to do if I were to have to implement a client. We
>should either be extremely restrictive, and require that the dhcp client
>release all application-requested lease bindings upon restart, or we should
>specify that the dhcp client will ignore and not renew any
>application-requested bindings. Either of those choices seems awkward to
>me. Either way, we'd have to require that the dhcp client would distinguish
>application requested bindings from stack- or interface-requested bindings.
>We either need to add a significant work-item to decide how the dhcp client
>should handle this hypothetical application-level capability, or we need to
>decide that we won't chase our tails trying to handle it until it exists.
>
>The client-id mechanism that's been proposed seems flexible enough that it
>can accomodate multiple requests for new bindings from a single host, even
>a host with a single physical interface. That suggests that the protocol
>can handle application-requested bindings whenever they show up, although
>dhcp client behavior will have to be carefully specified.
>
>-- Mark



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 20:04:00 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00437
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 20:03:59 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8800Ti17068;
	Thu, 7 Sep 2000 20:00:29 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8800Ki04667
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 20:00:20 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <S2PLQ4BA>; Thu, 7 Sep 2000 20:00:04 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC0E2@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 client identification...
Date: Thu, 7 Sep 2000 19:59:57 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Mark:

I agree with you that we can make the binding-id a single opaque value. And,
leave it up to clients as to how they use these for requesting addresses.

Going back to Ted's original message, he had 4 cases:
>	(a) Giving a DHCP client a unique identification that does
>	    not change when network hardware changes

The client could create binding-ids that support this if the client wishes
to implement it. While this is a good goal, I don't think it is a
requirement (for the protocol to specify). Especially in IPv6 as
autoconfigured addresses will change anyway if the network hardware changes.

>	(b) Providing a way to identify more than one instance of
>	    usage (I called these identity associations in my message
>	    about the DHCPv6 address model) within an individual client.

A change in the binding-id could be used to do this. The client is free to
generate any ids it wants. A change in binding-id is used to get a new
address.

>	(c) Providing a way for the server to tell that two identity
>	    associations actually represent one client.

The UUID (not binding-id) accomplishes this.

>	(d) Providing a way to have a single authentication
>	    key work with all of a client's identity associations.

The UUID accomplishes this.


- Bernie



-----Original Message-----
From: Mark Stapp [mailto:mjs@cisco.com]
Sent: Thursday, September 07, 2000 5:57 PM
To: DHCPv6 discussion list
Subject: RE: DHCPv6 client identification...


Bernie,

I hear you, but I still think that there are two kinds of info that are 
useful, and that both are available. As you noted in one of your earlier 
emails, some kind of link address must be available anyway. I think that 
that doesn't _have_ to be part of the binding identification, though some 
server implementations _might_ use that address to make decisions about 
lease bindings. I'm only trying to suggest that, rather than mandating that 
some physical characteristic be used in addition to the uuid, we only 
mandate the opaque binding-id. As you say, that only poses a problem for 
clients who've lost all of their state. The link address information is 
still available to the server, which may use it as part of its 
internal  implementation, but it doesn't _have_ to.

The common workstation client could simply use binding-id '0' (or '1') to 
refer to its single ethernet interface, and that interface could be changed 
without confusing the server or generating new address bindings. The laptop 
client in Ted's example must maintain enough state along with the leases it 
obtains to use the binding-ids consistently. If the laptop loses its state, 
it may inadvertently swap the relationship between the two interfaces and 
the two binding-ids. I guess I don't see more than two possibilities there:

1) the server doesn't care which interface either set of addresses is 
associated with. That is, the server doesn't distinguish between the two 
link-local addresses. For example, it doesn't detect wireless cards or give 
out different addresses to wireless cards. The server either notices that 
the relationship between links and binding-ids has swapped, decides that it 
cares about that, and swaps ip bindings to match, or it doesn't notice or 
doesn't care and it gives out the existing ip bindings that match the 
binding-ids.

2) the server cares which addresses are associated with each link address. 
The server either clears its existing binding info for the uuid+binding-id 
tuples, and creates new bindings, or it has recorded the previous link 
addresses, notices what has happened, and updates its bindings to reflect 
the new binding-id to interface relationship.

That's why I prefer an arbitrary binding-id. It saves the expense of 
describing how to use some semantically meaningful component, and it avoids 
over-specification of implementations' internal data structures. Some 
implementations will use link addresses, host-names, user-class strings, 
vendor-specific strings, etc. to make decisions, but none of those 
components has to be used in forming the client-id.

I absolutely agree that it would be very handy for clients to set a 'no 
state available' bit in their initial message as an indication that the 
client has no existing state for the uuid+binding-id tuple.

-- Mark

At 11:59 AM 9/7/00 -0400, you wrote:
>Mark:
>
>The only problem with the consistent ids across reboots is for clients that
>either don't have permanent storage or where the permanent storage has
>failed. But, in these cases we really should require the client to first
>release any resources it might have had. BTW: This is a reason I personally
>don't like the interface id just being a number such as 1, 2, 3. A more
>descriptive value means that the mac address or other identifier for the
>interface can be used and avoid some of the problems. Agreed that you
create
>others, such as by swapping out a card for a replacement; in that case the
>two are really identical and there is no reason for the client to get
>different addresses.
>
>Regarding the application issues, I think part of the application/DHCP API
>would be for the application to register continued interest in the address.
>One simple way to do this is to maintain a reference count on the address
in
>the DHCP client that is incremented when an application requests the
address
>and decremented when it releases it (note that this is an explicit release,
>not just it has no open connections - process rundown would need to notify
>the DHCP client). Once the reference count is 0, the DHCP client could
>either then release the address or just not renew it next time it expires.
>
>Across a reboot, the DHCP client would reset the reference count (and
>release the address). For a warm reboot, the application is still running
>and therefore the client takes the same steps it does for other addresses
to
>determine if they are still valid or whether the client has moved to a
>different network.
>
>- Bernie
>
>-----Original Message-----
>From: Mark Stapp [mailto:mjs@cisco.com]
>Sent: Thursday, September 07, 2000 11:06 AM
>To: DHCPv6 discussion list
>Subject: Re: DHCPv6 client identification...
>
>
>I think Ted uses a really interesting example. I'd like to suggest that
>client implementations MUST maintain a consistent association between the
>binding-id part of the identification and a physical interface as long as
>that interface has a DHCP-assigned address. In Ted's example:
>
> >address, or winds up consuming extra addresses, because the DHCP
> >client doesn't maintain a consistent identification for each
> >interface.   Consider the following sequence of events:
> >
> >(1) laptop is powered on with an ethernet card in pcmcia slot 1.
> >(2) laptop gets IP address using DHCP for {0, UUID}
> >(3) application starts, requests the client to get another identity
> >(4) client gets that identity using {1, UUID}
> >(5) user inserts 802.11 card, which acquires an identity using {2, UUID}
> >(6) user power cycles laptop
> >(7) laptop gets IP address for ethernet card using {0, UUID}
> >(8) laptop gets IP address for 802.11 card using {1, UUID}
> >(9) application starts, gets its IP address using {2, UUID}
> >
> >Note that the IP addresses assigned to {1, UUID} and {2, UUID} will
> >likely be different the second time through.
>
>The client has active bindings for the ethernet and the 802.11 devices, but
>doesn't use the binding-id part of the client-id consistently across
>re-starts. That shouldn't happen: the client should be required to use the
>client-id tuple consistently once it has acquired lease(s) with it.
>Requiring consistent use means that we can just use a single 16- or 32-bit
>binding-id along with the UUID to form the tuple: we don't need to require
>the client to manage 'interface indexes', we just have to require that the
>client use the binding-id consistently during the lifetime of the leases
>associated with it.
>
>The other part of this that's interesting is the 'application-requested'
>address situation. This example raises several very interesting questions.
>What does that application do with the address that it asked for across
>reboots? What do the stack and dhcp client do with the address? When this
>host reboots, its dhcp client and stack find three dhcp client-identities,
>and a set of one or more addresses associated with each of those three. I
>can imagine how the dhcp client handles the two binding sets that are
>associated with the interface cards, and I suppose that it pays attention
>to those leases' expiration times, and renews them pretty much
>indefinitely. Is the stack supposed to know which of the three was
>'application-requested'? Is there some way for the application to determine
>that one of the address sets was allocated by a previous instance of the
>application process? Is the stack supposed to prohibit other processes from
>using the address(es) associated with that application-requested
>allocation? Is the dhcp client supposed to keep renewing those addresses
>indefinitely, even if the application doesn't run before the leases'
>renewal time(s)? What if the application never runs again?
>
>I like the example a lot, but I dislike having to answer all of these
>questions now, in the absence of concrete proposals about the interaction
>between applications and the ipv6 dhcp client. I feel that we're trying to
>imagine a capability from the server-side, a capability that we all seem to
>think will be useful (and possibly inevitable). But the capability is
>fundamentally a client problem, and I don't personally see enough detail to
>know what I would have to do if I were to have to implement a client. We
>should either be extremely restrictive, and require that the dhcp client
>release all application-requested lease bindings upon restart, or we should
>specify that the dhcp client will ignore and not renew any
>application-requested bindings. Either of those choices seems awkward to
>me. Either way, we'd have to require that the dhcp client would distinguish
>application requested bindings from stack- or interface-requested bindings.
>We either need to add a significant work-item to decide how the dhcp client
>should handle this hypothetical application-level capability, or we need to
>decide that we won't chase our tails trying to handle it until it exists.
>
>The client-id mechanism that's been proposed seems flexible enough that it
>can accomodate multiple requests for new bindings from a single host, even
>a host with a single physical interface. That suggests that the protocol
>can handle application-requested bindings whenever they show up, although
>dhcp client behavior will have to be carefully specified.
>
>-- Mark



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 20:31:26 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00633
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 20:31:16 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e880UPi09095;
	Thu, 7 Sep 2000 20:30:25 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e880UFi11284
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 20:30:22 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 6979011BB; Thu,  7 Sep 2000 19:29:38 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id F378A13BB
	for <dhcp-v6@bucknell.edu>; Thu,  7 Sep 2000 19:29:37 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id UAA0000894360; Thu, 7 Sep 2000 20:29:10 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009080029.UAA0000894360@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 client identification... 
In-reply-to: Your message of "Thu, 07 Sep 2000 17:56:47 EDT."
             <4.2.0.58.20000907123921.01a65dc0@funnel.cisco.com> 
Date: Thu, 07 Sep 2000 20:29:09 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Mark,

>That's why I prefer an arbitrary binding-id. It saves the expense of 
>describing how to use some semantically meaningful component, and it avoids 
>over-specification of implementations' internal data structures. Some 
>implementations will use link addresses, host-names, user-class strings, 
>vendor-specific strings, etc. to make decisions, but none of those 
>components has to be used in forming the client-id.

I can live with this and prefer it.  My impression was the WG has always
wanted this specified?  

>I absolutely agree that it would be very handy for clients to set a 'no 
>state available' bit in their initial message as an indication that the 
>client has no existing state for the uuid+binding-id tuple.

I second that.

/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 23:43:29 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04377
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 23:43:29 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e883eGi21389;
	Thu, 7 Sep 2000 23:40:16 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e883e3i18663
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 23:40:03 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id 583FB23A4; Thu,  7 Sep 2000 22:39:48 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id B35292158
	for <dhcp-v6@bucknell.edu>; Thu,  7 Sep 2000 22:39:44 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id XAA0000917919; Thu, 7 Sep 2000 23:39:30 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009080339.XAA0000917919@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Design team teleconference, 8/31 
In-reply-to: Your message of "Fri, 01 Sep 2000 16:27:19 EDT."
             <4.3.1.2.20000901160948.00b30100@funnel.cisco.com> 
Date: Thu, 07 Sep 2000 23:39:28 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Was not clear what thread to post this too.  But one of the discussions
was the name of the messages.  The current DHCPv6 message names
correspond directly to Neighbor Discovery rfc 2462 thats where they came
from.  I think it more important to stay in synch with that part of IPv6
than DHCPv4.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 23:44:55 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04388
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 23:44:55 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e883iYi19861;
	Thu, 7 Sep 2000 23:44:34 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e883iPi02675
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 23:44:25 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 8347E586F; Thu,  7 Sep 2000 23:44:10 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id 6B7695576
	for <dhcp-v6@bucknell.edu>; Thu,  7 Sep 2000 23:44:10 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id XAA0000919423; Thu, 7 Sep 2000 23:44:08 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009080344.XAA0000919423@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Co nference Call Agenda) 
In-reply-to: Your message of "Fri, 01 Sep 2000 09:51:55 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC08E@lespaul.process.com> 
Date: Thu, 07 Sep 2000 23:44:07 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hi Bernie,

I have been thinking about this a lot and know very well what is needed
for IPv6 deployment.

I think we MUST permit Reconfigure and Reconfigure-Init with Multicast
to support site renumbering operations where stateless address
configuration is not used by the site.  It will permit a dhcpv6 server
to tell clients come get your new prefix NOW.  And in the response begin
the deprecation of old addresses.    

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep  7 23:51:39 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04482
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 7 Sep 2000 23:51:39 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e883pHi00810;
	Thu, 7 Sep 2000 23:51:17 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e883p7i27716
	for <dhcp-v6@bucknell.edu>; Thu, 7 Sep 2000 23:51:07 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id E9D6520FE; Thu,  7 Sep 2000 22:50:51 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id A2B742066
	for <dhcp-v6@bucknell.edu>; Thu,  7 Sep 2000 22:50:51 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id XAA0000919807; Thu, 7 Sep 2000 23:50:48 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009080350.XAA0000919807@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Design team teleconference, 8/31 
In-reply-to: Your message of "Thu, 07 Sep 2000 23:39:28 EDT."
             <200009080339.XAA0000917919@anw.zk3.dec.com> 
Date: Thu, 07 Sep 2000 23:50:47 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

dhcpv6 message names correct:
whoops specifically solicit and advertisement.  request, reply, and
release were from dhcpv4.  reconfigure was new concept.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Fri Sep  8 08:23:41 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21224
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 8 Sep 2000 08:23:41 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e88CKVi28698;
	Fri, 8 Sep 2000 08:20:31 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e88CKGi14208
	for <dhcp-v6@bucknell.edu>; Fri, 8 Sep 2000 08:20:16 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <S2PLQ4JS>; Fri, 8 Sep 2000 08:20:01 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC0E3@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 o
	n Co nference Call Agenda)
Date: Fri, 8 Sep 2000 08:19:57 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Jim:

OK. I was just wondering whether it was possible ... it would reduce
security issues as we push them off to the router advertisement messages.
Agreed that they are going to be useful if there are no routers (and perhaps
even if there are to effect transitions more quickly).

BTW: If there are no router advertisements received (after some period), I
assume a IPv6 host is supposed to attempt stateful address configuration (by
default).

- Bernie

-----Original Message-----
From: Jim Bound [mailto:bound@zk3.dec.com]
Sent: Thursday, September 07, 2000 11:44 PM
To: DHCPv6 discussion list
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18
on Co nference Call Agenda)


Hi Bernie,

I have been thinking about this a lot and know very well what is needed
for IPv6 deployment.

I think we MUST permit Reconfigure and Reconfigure-Init with Multicast
to support site renumbering operations where stateless address
configuration is not used by the site.  It will permit a dhcpv6 server
to tell clients come get your new prefix NOW.  And in the response begin
the deprecation of old addresses.    

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Fri Sep  8 10:19:00 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23251
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 8 Sep 2000 10:19:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e88EFXi30957;
	Fri, 8 Sep 2000 10:15:33 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e88EF8i09341
	for <dhcp-v6@bucknell.edu>; Fri, 8 Sep 2000 10:15:08 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id C8A8F1C25; Fri,  8 Sep 2000 09:14:51 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 69F771D13
	for <dhcp-v6@bucknell.edu>; Fri,  8 Sep 2000 09:14:51 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id KAA0001019178; Fri, 8 Sep 2000 10:14:25 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009081414.KAA0001019178@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 o n Co nference Call Agenda) 
In-reply-to: Your message of "Fri, 08 Sep 2000 08:19:57 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC0E3@lespaul.process.com> 
Date: Fri, 08 Sep 2000 10:14:24 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Bernie,

>OK. I was just wondering whether it was possible ... it would reduce
>security issues as we push them off to the router advertisement messages.
>Agreed that they are going to be useful if there are no routers (and perhaps
>even if there are to effect transitions more quickly).

Two things:

1.  I am not saying there are no routers on the LAN where clients exist
but something much more important as an assumption and important we
consider the assumption:

    Network Admins may not want to use stateless addrconf for 
    address configuration  but will have all routers set the M 
    bit in router advertrisements and tell clients go do address
    configuration with DHCPv6.  Its a customer/user policy decision
    to not use stateless addrconf on purpose.  We need to be prepared
    for that policy as we enhance DHCPv6 as a working group.

2.  If anyone wants to add to any of the Neighbor Discovery packets 
    they must go propose this in the IPng Working Group.  Like Mobile
    IPv6 has done.  We can't do that here the expertise is not wide
    enough on this list or enough of a quorum of IPv6 Neighbor 
    Discovery implementors (I think we only have Tim, Erik, Francis,
    and I as a note)????  And I think it should be done on IPng as 
    IETF policy IMO.

>BTW: If there are no router advertisements received (after some period), I
>assume a IPv6 host is supposed to attempt stateful address configuration (by
>default).

It has been left unspecified if there are no router advertisements so
that means if a client does not hear from a router our implementation
will go look for a dhcpv6 server, once we nail this spec down of course.

But if there are router advertisements I read the specs that an
implementaiton should not go look for DHCPv6 server unless the M bit is
set or the O bit (INFORM) is set.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 11 13:55:46 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07161
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 11 Sep 2000 13:55:45 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8BHpIb26067;
	Mon, 11 Sep 2000 13:51:22 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8BHp4b28439
	for <dhcp-v6@bucknell.edu>; Mon, 11 Sep 2000 13:51:05 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <SS53TDMP>; Mon, 11 Sep 2000 13:50:43 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC10A@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 o
	 n Co nference Call Agenda)
Date: Mon, 11 Sep 2000 13:50:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

FYI - 

-----Original Message-----
From: Jim Bound [mailto:bound@zk3.dec.com] 
Sent: Monday, September 11, 2000 9:48 AM
To: Bernie Volz
Cc: bound@zk3.dec.com
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18
o n Co nference Call Agenda)


Hi Bernie,

My systems were all down this weekend they had to do some wiring in 
our building and shutdown power for 36 hours.

>This is more for my own clarification (I didn't send it to the list):

OK.

>For IPv6, suppose there is a router. It sends router advertisements with
the
>'M' bit set. It also sends the prefix list with the 'A' bit clear for those
>prefixes that are stateful, meaning that the client can not autoconfigure
an
>address. In those advertisements are also the lifetimes. How do these
>lifetimes and any DHCPv6 specified lifetimes interact.

If the A bit is clear the implementation basically ignores the addresses
and lifetimes.  So they won't interact with DHCPv6.  

The WG needs to understand this.  If the A bit is not set there is no
problem.  If the A bit was set for the same prefixes that DHCPv6 are
using then clearly the lifetimes would be affected.  I would think the
same admin people will be in control and this is really a
"misconfiguration".  

But what I did in a prototype is marked the if6_net addresses as
stateless or stateful.  As I did the code for all this on T64 I know it
well.   If a router reduces the lifetime this is a problem and we either
need to release it or renew.  

I don't think want to get into the role of telling the server from the
client here are the NEW lifetimes the stateless says you should use Mr.
Server?  That defeats the point of "tight control by dhcpv6 server
adim".

>Recall that I raised this issue in an earlier discussion (a few days ago).

Yep wanted to wait to see where it went?

>If router advertisements deprecate the address before the DHCPv6 specified
>lifetimes do, should the client honor it or assume that the lease is
>"correct" (unless the DHCPv6 server sends it a reconfigure). Or might this
>be used as a trigger for the client to attempt to renew the address?

Well according to stateless and nd specs the client must change the
leases as stateless is the head cheese so to speak.

Should we bring this up on the list?

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 11 15:36:41 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08437
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 11 Sep 2000 15:36:41 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8BJWxb05527;
	Mon, 11 Sep 2000 15:32:59 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8BJWlb03609
	for <dhcp-v6@bucknell.edu>; Mon, 11 Sep 2000 15:32:47 -0400 (EDT)
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg14e1.nortelnetworks.com; Mon, 11 Sep 2000 15:32:28 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <S37AFRAP>; Mon, 11 Sep 2000 15:32:25 -0400
Message-ID: <F033F6FEF3F1D111BD150000F8CD1431049E4157@zcard007.ca.nortel.com>
From: "Peter Tam" <ptam@nortelnetworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 o n Co 
         nference Call Agenda)
Date: Mon, 11 Sep 2000 15:28:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C01C26.71DE4160"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C01C26.71DE4160
Content-Type: text/plain;
	charset="iso-8859-1"

Jim,

See in-line comments.

Regards....Peter Tam,
Nortel Networks

	-----Original Message-----
	From:	Jim Bound [SMTP:bound@zk3.dec.com]
	Sent:	Friday, September 08, 2000 10:14 AM
	To:	DHCPv6 discussion list
	Subject:	Re: Discussion Item - Reconfiguration in DHCPv6
(Items 8, 9, 18 o n Co  nference Call Agenda)

	Bernie,

	>OK. I was just wondering whether it was possible ... it would
reduce
	>security issues as we push them off to the router advertisement
messages.
	>Agreed that they are going to be useful if there are no routers
(and perhaps
	>even if there are to effect transitions more quickly).

	Two things:

	1.  I am not saying there are no routers on the LAN where clients
exist
	but something much more important as an assumption and important we
	consider the assumption:

	    Network Admins may not want to use stateless addrconf for 
	    address configuration  but will have all routers set the M 
	    bit in router advertrisements and tell clients go do address
	    configuration with DHCPv6.  Its a customer/user policy decision
	    to not use stateless addrconf on purpose.  We need to be
prepared
	    for that policy as we enhance DHCPv6 as a working group.

	2.  If anyone wants to add to any of the Neighbor Discovery packets 
	    they must go propose this in the IPng Working Group.  Like
Mobile
	    IPv6 has done.  We can't do that here the expertise is not wide
	    enough on this list or enough of a quorum of IPv6 Neighbor 
	    Discovery implementors (I think we only have Tim, Erik, Francis,
	    and I as a note)????  And I think it should be done on IPng as 
	    IETF policy IMO.

	>BTW: If there are no router advertisements received (after some
period), I
	>assume a IPv6 host is supposed to attempt stateful address
configuration (by
	>default).

	It has been left unspecified if there are no router advertisements
so
	that means if a client does not hear from a router our
implementation
	will go look for a dhcpv6 server, once we nail this spec down of
course.

	>> RFC2462, section 5.5.2  does specify that a host MUST default to
stateful autoconfiguration, if router advertisements are absent. But, you
are right, it does NOT say it must be DHCPv6:
	"If a link has no routers, a host MUST attempt to use stateful
autoconfiguration....."

	But if there are router advertisements I read the specs that an
	implementaiton should not go look for DHCPv6 server unless the M bit
is
	set or the O bit (INFORM) is set.

	regards,
	/jim
	

------_=_NextPart_001_01C01C26.71DE4160
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 =
o n Co  nference Call Agenda)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Jim,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">See in-line comments.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards....Peter Tam,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Nortel Networks</FONT>
</P>
<UL>
<P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original =
Message-----</FONT></A>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:&nbsp;&nbsp; Jim Bound =
[SMTP:bound@zk3.dec.com]</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D2 FACE=3D"Arial">Friday, September 08, 2000 10:14 AM</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">DHCPv6 discussion list</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D2 FACE=3D"Arial">Re: Discussion Item - =
Reconfiguration in DHCPv6 (Items 8, 9, 18 o n Co&nbsp; nference Call =
Agenda)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Bernie,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;OK. I was just wondering whether =
it was possible ... it would reduce</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;security issues as we push them =
off to the router advertisement messages.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;Agreed that they are going to be =
useful if there are no routers (and perhaps</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;even if there are to effect =
transitions more quickly).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Two things:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1.&nbsp; I am not saying there are no =
routers on the LAN where clients exist</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">but something much more important as =
an assumption and important we</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">consider the assumption:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Network Admins may =
not want to use stateless addrconf for </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; address =
configuration&nbsp; but will have all routers set the M </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; bit in router =
advertrisements and tell clients go do address</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; configuration with =
DHCPv6.&nbsp; Its a customer/user policy decision</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; to not use =
stateless addrconf on purpose.&nbsp; We need to be prepared</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; for that policy as =
we enhance DHCPv6 as a working group.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2.&nbsp; If anyone wants to add to any =
of the Neighbor Discovery packets </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; they must go =
propose this in the IPng Working Group.&nbsp; Like Mobile</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; IPv6 has =
done.&nbsp; We can't do that here the expertise is not wide</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; enough on this =
list or enough of a quorum of IPv6 Neighbor </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Discovery =
implementors (I think we only have Tim, Erik, Francis,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; and I as a =
note)????&nbsp; And I think it should be done on IPng as </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; IETF policy =
IMO.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;BTW: If there are no router =
advertisements received (after some period), I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;assume a IPv6 host is supposed to =
attempt stateful address configuration (by</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;default).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It has been left unspecified if there =
are no router advertisements so</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that means if a client does not hear =
from a router our implementation</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">will go look for a dhcpv6 server, =
once we nail this spec down of course.</FONT><U></U>
</P>

<P><U><FONT SIZE=3D2 FACE=3D"Arial">&gt;&gt;</FONT></U><U> <FONT =
SIZE=3D2 FACE=3D"Arial">RFC</FONT></U><U><FONT SIZE=3D2 =
FACE=3D"Arial">2462, section 5.5.2</FONT></U><U><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp; does specify that</FONT></U><U> <FONT SIZE=3D2 =
FACE=3D"Arial">a host</FONT></U><U><FONT SIZE=3D2 FACE=3D"Arial"> MUST =
d</FONT></U><U><FONT SIZE=3D2 FACE=3D"Arial">efault =
to</FONT></U><U><FONT SIZE=3D2 FACE=3D"Arial"></FONT></U><U> <FONT =
SIZE=3D2 FACE=3D"Arial">stateful autoconfiguration</FONT></U><U><FONT =
SIZE=3D2 FACE=3D"Arial">,</FONT></U><U><FONT SIZE=3D2 FACE=3D"Arial"> =
if router</FONT></U><U><FONT SIZE=3D2 FACE=3D"Arial"> =
advertisement</FONT></U><U><FONT SIZE=3D2 =
FACE=3D"Arial">s</FONT></U><U><FONT SIZE=3D2 FACE=3D"Arial"> are =
absent</FONT></U><U><FONT SIZE=3D2 FACE=3D"Arial">.</FONT></U><U> <FONT =
SIZE=3D2 FACE=3D"Arial">But, you are right, it does NOT say it must be =
DHCPv6</FONT></U><U><FONT SIZE=3D2 =
FACE=3D"Arial">:</FONT></U><U></U></P>

<P><U><FONT SIZE=3D2 FACE=3D"Arial">"</FONT></U><I><U><FONT SIZE=3D2 =
FACE=3D"Arial">If a link has no routers, a host MUST attempt to use =
stateful autoconf</FONT></U></I><I><U><FONT SIZE=3D2 =
FACE=3D"Arial">iguration....."</FONT></U></I><I></I>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">But if there are router advertisements =
I read the specs that an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">implementaiton should not go look for =
DHCPv6 server unless the M bit is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">set or the O bit (INFORM) is =
set.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">/jim</FONT>
<BR>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C01C26.71DE4160--



From owner-dhcp-v4@bucknell.edu  Tue Sep 12 06:54:20 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28904
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 12 Sep 2000 06:54:20 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8CAnsb04058;
	Tue, 12 Sep 2000 06:49:54 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8CAnib32425
	for <dhcp-v4@bucknell.edu>; Tue, 12 Sep 2000 06:49:44 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28503;
	Tue, 12 Sep 2000 06:49:43 -0400 (EDT)
Message-Id: <200009121049.GAA28503@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: dhcp-v4@bucknell.edu
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-dhc-subnet-option-07.txt
Date: Tue, 12 Sep 2000 06:49:42 -0400
Sender: owner-dhcp-v4@bucknell.edu
X-Sender: nsyracus@cnri.reston.va.us
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: The Subnet Selection Option for DHCP
	Author(s)	: G. Waters
	Filename	: draft-ietf-dhc-subnet-option-07.txt
	Pages		: 6
	Date		: 11-Sep-00
	
This memo defines a new DHCP option for selecting the subnet on which 
to allocate an address. This option would override a DHCP server's 
normal methods of selecting the subnet on which to allocate an address 
for a client.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-option-07.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-subnet-option-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-subnet-option-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000911143254.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-subnet-option-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-dhc-subnet-option-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000911143254.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-dhcp-v4@bucknell.edu  Tue Sep 12 11:54:41 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07458
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 12 Sep 2000 11:54:41 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8CFp8b24852;
	Tue, 12 Sep 2000 11:51:09 -0400 (EDT)
Received: from zrtps06s.us.nortel.com ([47.140.48.50])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8CFowb20797
	for <dhcp-v4@bucknell.edu>; Tue, 12 Sep 2000 11:50:58 -0400 (EDT)
Received: from zmers013 (actually zmers013.ca.nortel.com) 
          by zrtps06s.us.nortel.com; Tue, 12 Sep 2000 11:44:58 -0400
Received: from zcard00b.ca.nortel.com by zmers013;
          Tue, 12 Sep 2000 11:44:50 -0400
Received: from netgww (NET-GWW [47.130.100.112]) by zcard00b.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id STDCB8Z9; Tue, 12 Sep 2000 11:44:42 -0400
From: "Glenn Waters" <gww@nortelnetworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: I-D ACTION:draft-ietf-dhc-subnet-option-07.txt
Date: Tue, 12 Sep 2000 11:45:32 -0400
Message-ID: <00e001c01cd0$7cc38ea0$7064822f@netgww>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <200009121049.GAA28503@ietf.org>
X-Orig: <gww@americasm01.nt.com>
Reply-To: gww@nortelnetworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

FYI.

The only change between from the -06 version was the addition of the third
paragraph in the "Security Considerations" section. Many thanks to Thomas
Narten for his patience in helping with that piece of text. It is believed
that all the IESG concerns have been addressed, which means that this draft
should be ready to be published as a proposed standard.

Cheers, /gww

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Tuesday, September 12, 2000 06:50
To: DHCPv4 discussion list
Cc: dhcp-v4@bucknell.edu
Subject: I-D ACTION:draft-ietf-dhc-subnet-option-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Dynamic Host Configuration Working Group of
the IETF.

        Title           : The Subnet Selection Option for DHCP
        Author(s)       : G. Waters
        Filename        : draft-ietf-dhc-subnet-option-07.txt
        Pages           : 6
        Date            : 11-Sep-00

This memo defines a new DHCP option for selecting the subnet on which
to allocate an address. This option would override a DHCP server's
normal methods of selecting the subnet on which to allocate an address
for a client.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-option-07.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-dhc-subnet-option-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-dhc-subnet-option-07.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 12:56:47 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18941
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 12:56:47 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EGoFb04132;
	Thu, 14 Sep 2000 12:50:15 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EGo3b16990
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 12:50:03 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA26878 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 12:49:47 -0400 (EDT)
Message-Id: <4.3.1.2.20000914124611.00b6c830@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 14 Sep 2000 12:52:12 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: <200009070555.BAA0000750393@anw.zk3.dec.com>
References: <Your message of "Wed, 06 Sep 2000 13:33:11 PDT." <200009062033.e86KXBF01749@grosse.bisbee.fugue.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 01:55 AM 9/7/00 -0400, you wrote:
> >Do we need to make an explicit distinction here between "new" and
> >"renew"?

Well, suppose the client has just a single request it can make of the 
server: here's an identity association (IA) identifier - tell me the IP 
addresses (and associated lease lengths) associated with this IA.

If the server has no record of the IA (a "new" request), it assigns some 
addresses and returns them to the client.  If the server has previously 
assigned addresses to the IA, it simply returns those addresses, with 
(potentially) new lease lengths.  If the state of the IA has changed - 
e.g., some of the previously assigned addresses are no longer valid - the 
server returns the *current* addresses.

This strategy addresses the idempotency/identification problem with the 
explicit IA identifier, which gives the server a way to differentiate 
between successive requests for the same IA (address) or different IAs.

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 13:11:51 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19113
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 13:11:51 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EH8gb22612;
	Thu, 14 Sep 2000 13:08:42 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EH8Xb10939
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 13:08:33 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA29197 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 13:08:16 -0400 (EDT)
Message-Id: <4.3.1.2.20000914111231.00b66a30@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 14 Sep 2000 13:09:14 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 address model proposal...
In-Reply-To: <200009060729.e867TfC01827@grosse.bisbee.fugue.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I've finally had a chance to catch up on the DHCPv6 discussion threads.  My 
wife was ill and then in the hospital for a week, so I'm *way* behind on my 
e-mail...

Let me see if I have Ted's model - as amended by Bernie and Jim - right...

The basic unit of address allocation is the "identity association" 
(IA).  An IA has:

* a unique identifier
* one or more associated IP addresses
* a renewal time

Each IA is managed independently by the server and a client.  A client may 
be an OS or an application and there may be multiple DHCP clients within a 
single physical box.

Servers control the IAs.  That is, a server determines the addresses 
associated with an IA, perhaps based on hints from the client.  In 
particular, the client does not get to "ask for three addresses".  I also 
infer that the client does not get to ask for more addresses to be 
associated with an existing IA.

IA identifiers may be structured to express a relationship between 
clients.  E.g., identifiers from clients on the same computer might share a 
common prefix.

A client can make two requests to a server about an IA:

* Associate some IP addresses with this IA
* Renew this IA

The IP addresses associated with an IA have independent leases, which are 
also independent of the IA renewal time.  Renewing an IA is independent of 
extending the leases on the IP addresses associated with an IA.

Jim noted that "leases" may not be appropriate for IPv6 addresses, as an 
IPv6 address is either valid or invalid.  While valid, an address may be 
preferred or deprecated.  From RFC 2462, "IPv6 Stateless Address 
Autoconfiguration":

    IPv6 addresses are leased to an interface for a fixed (possibly
    infinite) length of time. Each address has an associated lifetime
    that indicates how long the address is bound to an interface. When a
    lifetime expires, the binding (and address) become invalid and the
    address may be reassigned to another interface elsewhere in the
    Internet. To handle the expiration of address bindings gracefully, an
    address goes through two distinct phases while assigned to an
    interface. Initially, an address is "preferred", meaning that its use
    in arbitrary communication is unrestricted. Later, an address becomes
    "deprecated" in anticipation that its current interface binding will
    become invalid.

So, RFC 2462 talks both about leasing and so should DHCP...

In any event, does this summary capture the consensus on the address model?

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 13:56:57 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19696
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 13:56:57 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EHpUb10136;
	Thu, 14 Sep 2000 13:51:30 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EHpNb30806
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 13:51:23 -0400 (EDT)
Received: from rdroms-nt.cisco.com (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA04788 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 13:51:02 -0400 (EDT)
Message-Id: <4.3.1.2.20000914133739.00b638a0@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 14 Sep 2000 13:53:15 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <rdroms@cisco.com>
Subject: Discussion threads from design team phone call
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Thanks to all who followed up with the recent discussion threads on issues 
from the design team phone call of a couple of weeks ago.

One of the outcomes of the design team phone call is the milestone of 
publishing a rev of the DHCPv6 spec by 9/30.  If the authors are going to 
meet that completion date, we need to come to consensus on the disposition 
of the discussion issues *soon*.

If you have any additional contributions to make, please speak up!  To help 
us come to closure, I'll ask the person responsible for each discussion 
issue to post a summary that we can review for completeness and 
correctness.  We're already several days late in finishing up these 
discussions, so we need to get these summaries posted in the next day or two...

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 14:20:28 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20018
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 14:20:28 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EIH7b20488;
	Thu, 14 Sep 2000 14:17:07 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EIGhb16478
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 14:16:45 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-211.ip.theriver.com [206.97.58.211]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id RAA10167 for <dhcp-v6@bucknell.edu>; Wed, 13 Sep 2000 17:23:07 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8EIEK019520 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 11:14:24 -0700 (MST)
Message-Id: <200009141814.e8EIEK019520@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Ralph Droms <droms@bucknell.edu> 
   of "Thu, 14 Sep 2000 12:52:12 -0400." <4.3.1.2.20000914124611.00b6c830@mail.bucknell.edu> 
Date: Thu, 14 Sep 2000 11:14:20 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> If the server has no record of the IA (a "new" request), it assigns some 
> addresses and returns them to the client.  If the server has previously 
> assigned addresses to the IA, it simply returns those addresses, with 
> (potentially) new lease lengths.  If the state of the IA has changed - 
> e.g., some of the previously assigned addresses are no longer valid - the 
> server returns the *current* addresses.

Right, that's what I had in mind too.   :')

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 14:23:29 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20073
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 14:23:28 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EIKFb11934;
	Thu, 14 Sep 2000 14:20:17 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EIISb14389
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 14:18:30 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA08687 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 14:18:12 -0400 (EDT)
Message-Id: <4.3.1.2.20000914141239.00b6c2e0@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 14 Sep 2000 14:20:38 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: RE: DHCPv6 client identification...
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEC0B8@lespaul.process.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 04:14 PM 9/6/00 -0400, you wrote:

>Also, if applications are going to be requesting addresses (we're all
>assuming this, aren't we?),

I need to remind us here that we have not firmly established a need for 
applications to request addresses.  We've decided that the example of 
multiple web services on a single host does not require 
application-specific IPv6 addresses (based on recent versions of 
HTTP).  We've also heard that the model of applications requesting 
addresses is not currently under consideration anywhere else in the IPv6 
spec development community.

We need to assess the current spec and proposals to determine if there is 
complexity in the spec that can be attribute solely to supporting 
application requests for addresses; if so, we need to understand that 
complexity and decide whether the complexity is worth the benefit of the 
additional function.

- Ralph




From owner-dhcp-v6@bucknell.edu  Thu Sep 14 14:26:03 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20129
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 14:26:03 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EIN6b18569;
	Thu, 14 Sep 2000 14:23:06 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EIIcb21513
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 14:18:41 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-211.ip.theriver.com [206.97.58.211]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id RAA10173 for <dhcp-v6@bucknell.edu>; Wed, 13 Sep 2000 17:25:06 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8EIGN019550 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 11:16:23 -0700 (MST)
Message-Id: <200009141816.e8EIGN019550@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Ralph Droms <droms@bucknell.edu> 
   of "Thu, 14 Sep 2000 13:09:14 -0400." <4.3.1.2.20000914111231.00b66a30@mail.bucknell.edu> 
Date: Thu, 14 Sep 2000 11:16:23 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> A client can make two requests to a server about an IA:
> 
> * Associate some IP addresses with this IA
> * Renew this IA

I thought we figured out that these were both the same request!   :'}
Or is the distinction that the latter case it may include some
addresses as a suggestion to the server, whereas in the former case it
will never do this?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 14:31:04 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20200
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 14:31:03 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EIPWb08231;
	Thu, 14 Sep 2000 14:25:32 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EIM7b18474
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 14:22:09 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA09227 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 14:21:49 -0400 (EDT)
Message-Id: <4.3.1.2.20000914135431.00b637f0@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 14 Sep 2000 14:24:15 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 client identification...
In-Reply-To: <200009060744.e867idC01841@grosse.bisbee.fugue.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted - I like your statement of the identification problem.

At 12:44 AM 9/6/00 -0700, Ted Lemon wrote:
>We had a nice discussion about client identifiers during the
>conference call.  The issues that I remember us talking about are:
>
>         (a) Giving a DHCP client a unique identification that does
>             not change when network hardware changes
>         (b) Providing a way to identify more than one instance of
>             usage (I called these identity associations in my message
>             about the DHCPv6 address model) within an individual client.
>         (c) Providing a way for the server to tell that two identity
>             associations actually represent one client.
>         (d) Providing a way to have a single authentication
>             key work with all of a client's identity associations.

(a) is important - I'd like the DHCP server to be able to know that my 
laptop is the same device whether it is plugged in to its docking station 
or connected through its PC card NIC.  (b) and (c) are related, I think - 
we'd like the server to differentiate IAs but be able to determine that two 
IAs come from the same DHCP client (physical computer?)  (d) simplifies the 
key management problem.

Not trying to be diffcult here - but what, exactly, is a "client"?  A 
physical device, a protocol stack, (potentially?) an application?  My 
understanding of (a)-(d) might change depending on the answer.

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 14:47:18 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20421
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 14:47:17 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EIibb16009;
	Thu, 14 Sep 2000 14:44:37 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EIiUb17717
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 14:44:31 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA12437 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 14:44:14 -0400 (EDT)
Message-Id: <4.3.1.2.20000914144010.00bbbc40@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 14 Sep 2000 14:45:58 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: <200009141816.e8EIGN019550@grosse.bisbee.fugue.com>
References: <Message from Ralph Droms <droms@bucknell.edu>
 <4.3.1.2.20000914111231.00b66a30@mail.bucknell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 11:16 AM 9/14/00 -0700, you wrote:

> > A client can make two requests to a server about an IA:
> >
> > * Associate some IP addresses with this IA
> > * Renew this IA
>
>I thought we figured out that these were both the same request!   :'}

I took this from your original message:

>I think there are actually only two questions a client ever needs to
>ask the server: "please associate an IP address with this identity,"
>and "please renew the association for this identity."

We might have figured out the are both the same request in another message 
- I skimmed through all the messages pretty quickly and may have missed 
it.  In fact, I made a similar suggestion in another message:

>Well, suppose the client has just a single request it can make of the 
>server: here's an identity association (IA) identifier - tell me the IP 
>addresses (and associated lease lengths) associated with this IA.
>
>If the server has no record of the IA (a "new" request), it assigns some 
>addresses and returns them to the client.  If the server has previously 
>assigned addresses to the IA, it simply returns those addresses, with 
>(potentially) new lease lengths.  If the state of the IA has changed - 
>e.g., some of the previously assigned addresses are no longer valid - the 
>server returns the *current* addresses.

- Ralph





From owner-dhcp-v6@bucknell.edu  Thu Sep 14 14:49:40 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20466
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 14:49:39 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EIkvb28321;
	Thu, 14 Sep 2000 14:46:57 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EIkIb32707
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 14:46:19 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA12670 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 14:46:01 -0400 (EDT)
Message-Id: <4.3.1.2.20000914144752.00b59480@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 14 Sep 2000 14:48:27 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: <200009141814.e8EIEK019520@grosse.bisbee.fugue.com>
References: <Message from Ralph Droms <droms@bucknell.edu>
 <4.3.1.2.20000914124611.00b6c830@mail.bucknell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 11:14 AM 9/14/00 -0700, you wrote:

> > If the server has no record of the IA (a "new" request), it assigns some
> > addresses and returns them to the client.  If the server has previously
> > assigned addresses to the IA, it simply returns those addresses, with
> > (potentially) new lease lengths.  If the state of the IA has changed -
> > e.g., some of the previously assigned addresses are no longer valid - the
> > server returns the *current* addresses.
>
>Right, that's what I had in mind too.   :')

Looks like our e-mail is crossing in flight and we're having a time-delayed 
agreement...

- Ralph




From owner-dhcp-v6@bucknell.edu  Thu Sep 14 14:52:42 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20531
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 14:52:41 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EInqb32081;
	Thu, 14 Sep 2000 14:49:52 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EInVb19746
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 14:49:32 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-211.ip.theriver.com [206.97.58.211]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id RAA10254 for <dhcp-v6@bucknell.edu>; Wed, 13 Sep 2000 17:56:00 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8EIlE019982 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 11:47:14 -0700 (MST)
Message-Id: <200009141847.e8EIlE019982@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 client identification... 
In-Reply-To: Message from Ralph Droms <droms@bucknell.edu> 
   of "Thu, 14 Sep 2000 14:24:15 -0400." <4.3.1.2.20000914135431.00b637f0@mail.bucknell.edu> 
Date: Thu, 14 Sep 2000 11:47:14 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Not trying to be diffcult here - but what, exactly, is a "client"?  A 
> physical device, a protocol stack, (potentially?) an application?  My 
> understanding of (a)-(d) might change depending on the answer.

That's a good question.  I think the answer is "that collection of
programs running on a single computer that interact on the DHCP
protocol port and respond to DHCP requests."  I think in order to
implement this you probably either have to have all of the identity
association state machines either running as part of the same program,
or you have to have an API on your computer that acts as a rendezvous
point for seperate programs each of which is running one or more of
the identity associations.

I don't think we talked about this, but this has implications for the
DHCP Reconfigure message.   The Reconfigure message has to tell the
client which identity association to renew (or to renew all of them, I
guess).

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 14:56:37 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20693
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 14:56:36 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EIrSb25301;
	Thu, 14 Sep 2000 14:53:28 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EIrKb29291
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 14:53:21 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-211.ip.theriver.com [206.97.58.211]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id RAA10267 for <dhcp-v6@bucknell.edu>; Wed, 13 Sep 2000 17:59:48 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8EIp2020055 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 11:51:02 -0700 (MST)
Message-Id: <200009141851.e8EIp2020055@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Ralph Droms <droms@bucknell.edu> 
   of "Thu, 14 Sep 2000 14:45:58 -0400." <4.3.1.2.20000914144010.00bbbc40@mail.bucknell.edu> 
Date: Thu, 14 Sep 2000 11:51:02 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> We might have figured out the are both the same request in another message 
> - I skimmed through all the messages pretty quickly and may have missed 
> it.  In fact, I made a similar suggestion in another message:

Right, that's where I took the agreement from.  Maybe I hadn't agreed
to this before, though... :'}

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 14:58:48 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20742
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 14:58:48 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EIu6b01761;
	Thu, 14 Sep 2000 14:56:06 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EIrpb30414
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 14:53:51 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-211.ip.theriver.com [206.97.58.211]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id SAA10277 for <dhcp-v6@bucknell.edu>; Wed, 13 Sep 2000 18:00:19 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8EIpX020070 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 11:51:33 -0700 (MST)
Message-Id: <200009141851.e8EIpX020070@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Ralph Droms <droms@bucknell.edu> 
   of "Thu, 14 Sep 2000 14:48:27 -0400." <4.3.1.2.20000914144752.00b59480@mail.bucknell.edu> 
Date: Thu, 14 Sep 2000 11:51:33 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Looks like our e-mail is crossing in flight and we're having a time-delayed 
> agreement...

I think you're right.   :')   I should be slower off the mark, I guess.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 15:08:26 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22678
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 15:08:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EJ3Jb06488;
	Thu, 14 Sep 2000 15:03:19 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EJ36b22910
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 15:03:07 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA15040 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 15:02:49 -0400 (EDT)
Message-Id: <4.3.1.2.20000914145102.00b774b0@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 14 Sep 2000 15:00:21 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: RE: DHCPv6 Relay Changes
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEC0C3@lespaul.process.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 09:28 PM 9/6/00 -0400, you wrote:
>While I understand the forward (client to relay to server) message traffic,
>the reverse traffic isn't clear. I assume the server sends back the message
>to the relay without having to encapsulate it?

For simplicity and security, I would guess the return traffic is 
encapsulated as well.

>If you allow the multiple encapsulations (one for each relay), how does the
>reverse traffic occur?

I didn't see any reference to multiple encapsulations in Barr's note - did 
I miss it?  In any event, we probably need multiple encapsulations to 
accommodate authenticated relay options.

>  It goes to the relay nearest the client since it is
>the only one that can communicate with the client?

In case of multiple relays - note that processing a DHCP message in 
multiple realy agents is an unusual event - I would guess we want to unwrap 
the messages one at a time through the reverse path.

- Ralph




From owner-dhcp-v6@bucknell.edu  Thu Sep 14 15:08:28 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22689
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 15:08:28 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EJ5cb16813;
	Thu, 14 Sep 2000 15:05:38 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EJ37b32345
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 15:03:07 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA15047 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 15:02:50 -0400 (EDT)
Message-Id: <4.3.1.2.20000914150033.00b59e00@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 14 Sep 2000 15:01:34 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 Relay Changes 
In-Reply-To: <200009070659.CAA0000757316@anw.zk3.dec.com>
References: <Your message of "Wed, 06 Sep 2000 21:28:46 EDT." <63D30D6E10CFD11190A90000F805FE8602BEC0C3@lespaul.process.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 02:59 AM 9/7/00 -0400, you wrote:
>Barr/folks,
>
>Is this really encapsulation?
>
>or
>
>A new relay extension msg type to encapsulate client solicits and
>requests.
>
>At the design meeting I was thinking real encapsulation.

I was imagining a new message extension type that carries the client 
message in another DHCP message between the relay and the server.

- Ralph




From owner-dhcp-v6@bucknell.edu  Thu Sep 14 15:14:40 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22760
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 15:14:40 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EJBmb00676;
	Thu, 14 Sep 2000 15:11:48 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EJBjb08221
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 15:11:45 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA16129 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 15:11:27 -0400 (EDT)
Message-Id: <4.3.1.2.20000914151229.00ae2920@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 14 Sep 2000 15:13:51 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: <200009141851.e8EIp2020055@grosse.bisbee.fugue.com>
References: <Message from Ralph Droms <droms@bucknell.edu>
 <4.3.1.2.20000914144010.00bbbc40@mail.bucknell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 11:51 AM 9/14/00 -0700, you wrote:

> > We might have figured out the are both the same request in another message
> > - I skimmed through all the messages pretty quickly and may have missed
> > it.  In fact, I made a similar suggestion in another message:
>
>Right, that's where I took the agreement from.  Maybe I hadn't agreed
>to this before, though... :'}


Ah - I had just made that as an off-hand observation.  I had no idea 
someone actually agreed with me.

Perhaps it comes from spending so much time one-on-one with my kids over 
the last week or two.  They *never* agree with me...

- Ralph




From owner-dhcp-v6@bucknell.edu  Thu Sep 14 15:34:26 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22998
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 15:34:25 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EJVdb04084;
	Thu, 14 Sep 2000 15:31:39 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EJVQb08706
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 15:31:26 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <SS53T2BV>; Thu, 14 Sep 2000 15:31:10 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC158@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Thu, 14 Sep 2000 15:31:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

In agreement with the two basic requests.

The first (Associate some IP addresses with this IA) request is really lease
me some addresses (or lease me what addresses I might have had in the past)
and the second is the renewal request.

We did have some open issues with these requests that were under discussion.

- I believe we all agreed that allowing the client to supply a list of
prefixes for addresses the client wanted is allowed. The server can supply
additional addresses and might not assign addresses for all supplied
prefixes.

- I believe the renewal was a bigger issue because it wasn't clear whether a
client could "renew" an individual address or had to renew all of them. The
issue also required us to resolve whether lifetimes are per address or per
IA, which was never fully resolved. As with router prefix advertisements, I
personnally feel that the lifetimes should be per address, not per IA (ie,
the "lease" each address includes per address lifetimes, rather than a
single lifetime for all addresses).

The way the list of requests below reads ("renew this IA") kind of implies
that one leases IAs and not addresses. Perhaps you've implied to solve the
problem by saying all addresses for an IA have the same lifetimes?

- Bernie Volz



-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Thursday, September 14, 2000 2:46 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...


At 11:16 AM 9/14/00 -0700, you wrote:

> > A client can make two requests to a server about an IA:
> >
> > * Associate some IP addresses with this IA
> > * Renew this IA
>
>I thought we figured out that these were both the same request!   :'}

I took this from your original message:

>I think there are actually only two questions a client ever needs to
>ask the server: "please associate an IP address with this identity,"
>and "please renew the association for this identity."

We might have figured out the are both the same request in another message 
- I skimmed through all the messages pretty quickly and may have missed 
it.  In fact, I made a similar suggestion in another message:

>Well, suppose the client has just a single request it can make of the 
>server: here's an identity association (IA) identifier - tell me the IP 
>addresses (and associated lease lengths) associated with this IA.
>
>If the server has no record of the IA (a "new" request), it assigns some 
>addresses and returns them to the client.  If the server has previously 
>assigned addresses to the IA, it simply returns those addresses, with 
>(potentially) new lease lengths.  If the state of the IA has changed - 
>e.g., some of the previously assigned addresses are no longer valid - the 
>server returns the *current* addresses.

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 15:38:13 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23022
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 15:38:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EJYqb05219;
	Thu, 14 Sep 2000 15:34:52 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EJWcb22689
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 15:32:38 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA18874 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 15:32:22 -0400 (EDT)
Message-Id: <4.3.1.2.20000914152733.00b15700@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 14 Sep 2000 15:32:35 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: Design team teleconference, 8/31 
In-Reply-To: <200009080339.XAA0000917919@anw.zk3.dec.com>
References: <Your message of "Fri, 01 Sep 2000 16:27:19 EDT." <4.3.1.2.20000901160948.00b30100@funnel.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 11:39 PM 9/7/00 -0400, you wrote:
>Was not clear what thread to post this too.  But one of the discussions
>was the name of the messages.

Right - I'm not sure we actually got that thread kicked off.  It was my 
question - do we need different semantics and message names for DHCPv6 or 
can we reuse the technology from DHCPv4?

For example, the DHCPv6 Solicit message now acts pretty much like the 
DHCPv4 DHCPDISCOVER message (allowing for differences in the message 
formats).  The Advertise message acts pretty much like a DHCPOFFER, except 
the Advertise doesn't include any offered parameters.  is there a reason 
for the difference or could we include parameters in the DHCPv6 message and 
call it a DHCPOFFER?

>   The current DHCPv6 message names
>correspond directly to Neighbor Discovery rfc 2462 thats where they came
>from.  I think it more important to stay in synch with that part of IPv6
>than DHCPv4.

If the messages are really different messages - with different semantics - 
then sure, we should go with RFC 2462.  If the DHCPv6 messages walk and 
quack like DISCOVER/OFFER/REQUEST/ACK then that's what we oughta call 'em...

- Ralph




From owner-dhcp-v6@bucknell.edu  Thu Sep 14 15:42:12 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23082
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 15:42:09 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EJbDb15554;
	Thu, 14 Sep 2000 15:37:13 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EJZbb10722
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 15:35:37 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <SS53T2B9>; Thu, 14 Sep 2000 15:35:21 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC159@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 Relay Changes
Date: Thu, 14 Sep 2000 15:35:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I agree with Ralph - I was imagining the same.

I don't believe we want to do IP layer encapsulation since the DHCP relay
agent has typically run above the IP layer (above UDP) and I don't think we
want to change that. Especially when you consider the kinds of things that
Relay Agents might be doing these days (CMTS devices). Keeping relay agents
at the application layer is the right thing to do.

-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Thursday, September 14, 2000 3:02 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 Relay Changes


At 02:59 AM 9/7/00 -0400, you wrote:
>Barr/folks,
>
>Is this really encapsulation?
>
>or
>
>A new relay extension msg type to encapsulate client solicits and
>requests.
>
>At the design meeting I was thinking real encapsulation.

I was imagining a new message extension type that carries the client 
message in another DHCP message between the relay and the server.

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 15:50:28 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23181
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 15:50:28 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EJlkb15179;
	Thu, 14 Sep 2000 15:47:46 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EJlUb31576
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 15:47:30 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <SS53T2CS>; Thu, 14 Sep 2000 15:47:15 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC15B@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Thu, 14 Sep 2000 15:47:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Opps ... I should have read the longer email first. In that message, Ralph
indicates that each address has its own lifetimes.

-----Original Message-----
From: Bernie Volz [mailto:Volz@ipworks.com]
Sent: Thursday, September 14, 2000 3:31 PM
To: DHCPv6 discussion list
Subject: RE: DHCPv6 address model proposal...


In agreement with the two basic requests.

The first (Associate some IP addresses with this IA) request is really lease
me some addresses (or lease me what addresses I might have had in the past)
and the second is the renewal request.

We did have some open issues with these requests that were under discussion.

- I believe we all agreed that allowing the client to supply a list of
prefixes for addresses the client wanted is allowed. The server can supply
additional addresses and might not assign addresses for all supplied
prefixes.

- I believe the renewal was a bigger issue because it wasn't clear whether a
client could "renew" an individual address or had to renew all of them. The
issue also required us to resolve whether lifetimes are per address or per
IA, which was never fully resolved. As with router prefix advertisements, I
personnally feel that the lifetimes should be per address, not per IA (ie,
the "lease" each address includes per address lifetimes, rather than a
single lifetime for all addresses).

The way the list of requests below reads ("renew this IA") kind of implies
that one leases IAs and not addresses. Perhaps you've implied to solve the
problem by saying all addresses for an IA have the same lifetimes?

- Bernie Volz



-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Thursday, September 14, 2000 2:46 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...


At 11:16 AM 9/14/00 -0700, you wrote:

> > A client can make two requests to a server about an IA:
> >
> > * Associate some IP addresses with this IA
> > * Renew this IA
>
>I thought we figured out that these were both the same request!   :'}

I took this from your original message:

>I think there are actually only two questions a client ever needs to
>ask the server: "please associate an IP address with this identity,"
>and "please renew the association for this identity."

We might have figured out the are both the same request in another message 
- I skimmed through all the messages pretty quickly and may have missed 
it.  In fact, I made a similar suggestion in another message:

>Well, suppose the client has just a single request it can make of the 
>server: here's an identity association (IA) identifier - tell me the IP 
>addresses (and associated lease lengths) associated with this IA.
>
>If the server has no record of the IA (a "new" request), it assigns some 
>addresses and returns them to the client.  If the server has previously 
>assigned addresses to the IA, it simply returns those addresses, with 
>(potentially) new lease lengths.  If the state of the IA has changed - 
>e.g., some of the previously assigned addresses are no longer valid - the 
>server returns the *current* addresses.

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 15:56:29 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23223
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 15:56:29 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EJrSb10202;
	Thu, 14 Sep 2000 15:53:28 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EJrBb06071
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 15:53:11 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <SS53T2C0>; Thu, 14 Sep 2000 15:52:56 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC15C@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Design team teleconference, 8/31
Date: Thu, 14 Sep 2000 15:52:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

While I agree with Ralph's reasoning for using the DHCPv4 messages, I do
believe that we should use different names because:
- The message formats are no where near close
- The behavior of the protocol (and what the messages cause to occur and
communicate) is different in significant ways

I think it will REDUCE confusion in the long run to use different names
because we'll know instantly what we're taking about when we say SOLICIT
message. If use DISCOVER for both V4 and V6, we'll constantly have to say
"v4 DISCOVER or v6 DISCOVER".

So in summary, I think they are different enough to warrant different names.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Thursday, September 14, 2000 3:33 PM
To: DHCPv6 discussion list
Subject: Re: Design team teleconference, 8/31


At 11:39 PM 9/7/00 -0400, you wrote:
>Was not clear what thread to post this too.  But one of the discussions
>was the name of the messages.

Right - I'm not sure we actually got that thread kicked off.  It was my 
question - do we need different semantics and message names for DHCPv6 or 
can we reuse the technology from DHCPv4?

For example, the DHCPv6 Solicit message now acts pretty much like the 
DHCPv4 DHCPDISCOVER message (allowing for differences in the message 
formats).  The Advertise message acts pretty much like a DHCPOFFER, except 
the Advertise doesn't include any offered parameters.  is there a reason 
for the difference or could we include parameters in the DHCPv6 message and 
call it a DHCPOFFER?

>   The current DHCPv6 message names
>correspond directly to Neighbor Discovery rfc 2462 thats where they came
>from.  I think it more important to stay in synch with that part of IPv6
>than DHCPv4.

If the messages are really different messages - with different semantics - 
then sure, we should go with RFC 2462.  If the DHCPv6 messages walk and 
quack like DISCOVER/OFFER/REQUEST/ACK then that's what we oughta call 'em...

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 16:37:56 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23651
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 16:37:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EKWkb04444;
	Thu, 14 Sep 2000 16:32:46 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EKWdb03329
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 16:32:39 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <SS53T21Y>; Thu, 14 Sep 2000 16:32:19 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC160@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion Item - Using DHCPv4 options in DHCPv6 (Item 6 on C
	onfe rence Call Agenda)
Date: Thu, 14 Sep 2000 16:32:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

The only feedback I got regarding this issue was from Jim Bound who said:

	-----Original Message-----
	From: Jim Bound [mailto:bound@zk3.dec.com]
	Sent: Thursday, September 07, 2000 12:34 AM
	To: DHCPv6 discussion list
	Subject: Re: Discussion Item - Using DHCPv4 options in DHCPv6 (Item
6 on
	Confe rence Call Agenda)


	Hi Bernie,

	I think this is a good idea.  As a note we did go thru the dhcpv4
	options (not the latest ones) and tried to copy them to dhcpv6 exts
	draft.  I strongly agree that it will be much easier for us in the
	future to look at options this way too.

	regards,
	/jim,

So, I assume everyone else is in agreement?

-----Original Message-----
From: Bernie Volz [mailto:Volz@ipworks.com]
Sent: Friday, September 01, 2000 9:41 AM
To: DHCPv6 discussion list
Subject: Discussion Item - Using DHCPv4 options in DHCPv6 (Item 6 on
Confe rence Call Agenda)


During the DHCPv6 conference call on Thursday, August 31st, I was assigned
the "responsibility" of coming to a resolution on item 6 on Ralph's compiled
list:

6. Where appropriate, keep v4 and v6 options/extensions "the
    same". Use the same option numbers. Use the same format (except for
    16-bit type/length).

As I was one of the people that proposed this, let me give you my reasons.

While there are many options in DHCPv4 that are no appropriate to DHCPv6
(either because the options configure things that aren't appropriate or
don't exist in IPv6 or because they contain internet addresses), there are
many other options that are appropriate to both (such as domain names and
URLs). I'm not proposing that all DHCPv4 options be valid in DHCPv6. I'm
just proposing that we reserve option (or extension) numbers from 0 to 255
in DHCPv6 and adopt any of the DHCPv4 options that make sense in DHCPv6 and
use the same option numbers.

>From some point forward, all new DHCP options RFCs should have a statement
that indicates whether the option is valid in DHCPv4 and/or DHCPv6. And, for
those that are appropriate to DHCPv4, we use whatever limitations exist on
the number space (<256). For DHCPv6 only options, any number is valid.

For existing DHCPv4 options that are also valid for DHCPv6, we now only need
to write a document that indicates what these options are and that the
format of the option data is the same, though the option header now uses
16-bit option number and length. We don't have to re-specify the behavoir of
the client and server with respect to these options. Note also that while we
may feel that having DHCPv6 options for the DHCPv4 NDS ones makes little
sense, perhaps someone will find a need. In that case, they could easily
issue a 1 page draft (excluding the draft boiler-plate requirements) that
says DHCPv4 option x is valid on DHCPv6 with a 16-bit option number and
length. I think we'd all agree that reviewing these drafts is much easier
and faster than having to review the entire text again (since we'd then
likely want to add other rewording, etc.).

I am not proposing that we re-format the data of options (such as those that
carry internet addresses) for those would not work "as is" for DHCPv6. If
DHCPv6 needs that option, a new option should be defined to carry the data
appropriate to DHCPv6. Only those options where the data can be used "as is"
should be adopted in DHCPv6.

IANA must also only assign numbers from ONE space instead of having two
option spaces (DHCPv4 and DHCPv6) to consider. Though, IANA would need to be
instructed that options that apply to DHCPv4 would need to be assigned from
the current DHCPv4 space (0..127) and that DHCPv6 only options must be
assigned numbers >255.

This also allows for simplier configuration of DHCP servers should a server
support both DHCPv4 and DHCPv6. Or in storing options data in a database or
LDAP repository (as an author of the LDAP schema for DHCP, I'd like us not
to have a "dhcpv4option" and "dhcpv6option" attribute - much easier to have
just a "dhcpoption" attribute which can store either).

Doing the work do go through all of the DHCPv4 options to determine
applicability to DHCPv6 is likely not an easy task. So, my suggestion is
that as we develop the options we want for DHCPv6, we look to the DHCPv4
options. If we find an identical option in DHCPv4, we use that option number
and option data format. If someone later wants to add another option, they
write that 1 page draft I mentioned earlier.

What's the impact to DHCPv6 for doing this? I think almost nothing except to
reserve options 0 to 255 and use the DHCPv4 option numbers (and data format)
if and only if appropriate.

So, with that ... let's start the discussion. As we did not set a deadline
at the conference call, other than stating a week, and given the Labor Day
holiday, I'd like to conclude this discussion by end of day Friday,
September 8.

- Bernie Volz
  IPWorks, Inc.



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 16:58:51 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23923
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 16:58:51 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EKu5b07744;
	Thu, 14 Sep 2000 16:56:05 -0400 (EDT)
Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EKu0b04587
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 16:56:00 -0400 (EDT)
Received: from dns.dhcp.org (dns.dhcp.org [134.82.56.120])
	by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id QAA20960;
	Thu, 14 Sep 2000 16:55:55 -0400 (EDT)
Date: Thu, 14 Sep 2000 16:55:55 -0400 (EDT)
From: "Ralph E. Droms" <droms@bucknell.edu>
X-Sender: droms@leo
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
cc: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Design team teleconference, 8/31
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEC15C@lespaul.process.com>
Message-ID: <Pine.GSO.4.03.10009141652540.20956-100000@leo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

On Thu, 14 Sep 2000, Bernie Volz wrote:
> While I agree with Ralph's reasoning for using the DHCPv4 messages, I do
> believe that we should use different names because:
> - The message formats are no where near close

I claim the message formats aren't important in this context.  A
pretty-printer can make them look the same when snooping packets...

> - The behavior of the protocol (and what the messages cause to occur and
> communicate) is different in significant ways

I don't believe that we've shown that the messages *must* have different
semantics.  I gave two examples of how Solicit/DHCPDISCOVER and
Advertise/DHCPOFFER have come to have quite similar semantics.  I'd like
to see a convincing argument that the remaining differences are important
to the operation of DHCPng.

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 17:21:12 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24858
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 17:21:12 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8ELGQb12921;
	Thu, 14 Sep 2000 17:16:26 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8ELGBb20150
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 17:16:11 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-211.ip.theriver.com [206.97.58.211]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA10723 for <dhcp-v6@bucknell.edu>; Wed, 13 Sep 2000 20:22:39 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8ELDW021912 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 14:13:34 -0700 (MST)
Message-Id: <200009142113.e8ELDW021912@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 Relay Changes 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Thu, 14 Sep 2000 15:35:20 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC159@lespaul.process.com> 
Date: Thu, 14 Sep 2000 14:13:32 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> I don't believe we want to do IP layer encapsulation since the DHCP relay
> agent has typically run above the IP layer (above UDP) and I don't think we
> want to change that. Especially when you consider the kinds of things that
> Relay Agents might be doing these days (CMTS devices). Keeping relay agents
> at the application layer is the right thing to do.

Right, that was what I was thinking too - that's why I suggested
encapsulating the client's entire message in a DHCPv6 extension of a
new DHCP Relay message.   The relay agent can then optionally sign the
message or include additional information.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 17:29:46 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25452
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 17:29:45 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8ELR3b32159;
	Thu, 14 Sep 2000 17:27:03 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8ELQrb13972
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 17:26:53 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-211.ip.theriver.com [206.97.58.211]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA10763 for <dhcp-v6@bucknell.edu>; Wed, 13 Sep 2000 20:33:22 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8ELOP022091 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 14:24:25 -0700 (MST)
Message-Id: <200009142124.e8ELOP022091@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Design team teleconference, 8/31 
In-Reply-To: Message from "Ralph E. Droms" <droms@bucknell.edu> 
   of "Thu, 14 Sep 2000 16:55:55 -0400." <Pine.GSO.4.03.10009141652540.20956-100000@leo> 
Date: Thu, 14 Sep 2000 14:24:25 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> I'd like to see a convincing argument that the remaining differences
> are important to the operation of DHCPng.

I don't think they are.   I don't mind the new semantics, and I think
they make sense, but the old semantics make sense too.   I think that
with the additional addressing complexity of DHCPng, the old semantics
probably aren't as useful, but that doesn't mean we *have* to get rid
of them.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 18:53:18 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27106
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 18:53:17 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8EMlpb03990;
	Thu, 14 Sep 2000 18:47:51 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8EMlXb01439
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 18:47:33 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-211.ip.theriver.com [206.97.58.211]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id VAA10927 for <dhcp-v6@bucknell.edu>; Wed, 13 Sep 2000 21:54:00 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8EMiu023074 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 15:44:58 -0700 (MST)
Message-Id: <200009142244.e8EMiu023074@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Thu, 14 Sep 2000 15:47:13 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC15B@lespaul.process.com> 
Date: Thu, 14 Sep 2000 15:44:56 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> - I believe the renewal was a bigger issue because it wasn't clear whether a
> client could "renew" an individual address or had to renew all of them. The
> issue also required us to resolve whether lifetimes are per address or per
> IA, which was never fully resolved. As with router prefix advertisements, I
> personnally feel that the lifetimes should be per address, not per IA (ie,
> the "lease" each address includes per address lifetimes, rather than a
> single lifetime for all addresses).
> 
> The way the list of requests below reads ("renew this IA") kind of implies
> that one leases IAs and not addresses. Perhaps you've implied to solve the
> problem by saying all addresses for an IA have the same lifetimes?

I think the solution to the problem is that each address should have
its own lifetime, but that the identity association should have a
renewal time.  If the DHCP server isn't going to renew a deprecated
address, it can set the identity association renewal time to be after
the lifetime of that address expires.  Excluding deprecated addresses,
the DHCP server would then use the shortest lifetime of the remaining
addresses to figure the lease time for the identity association.   The
DHCP client would then always renew at the appropriate percentage of
the identity association renewal time.

So what I'm suggesting is that we seperate out the lifetime concept
from the renewal time concept.  The client tracks lifetimes in the
sense that if an address's lifetime expires, the client drops it.  But
it always renews identity associations, not address lifetimes.  So on
the client side you have a drop dead timer on each lifetime that's
initialized each time an address is installed as a result of the
server assigning it.  The client also has to remember that each of
these addresses is part of an identity association, and drop the
addresses if the server doesn't renew them.  But in terms of asking
for renewals, it renews all the addresses associated with an IA at
once, even if some of them have much longer lifetimes than others.

The implementation looks something like this (I've simplified the
initial DHCP Reply processing - really, both DHCP Replies are
processed as in the description of the second DHCP Reply):

Receives DHCP Reply:
   address A: lifetime = X (deprecated)
   address B: lifetime = 2X
   address C: lifetime = 3X
   renewal time: 2Xk (k = percentage of lease lifetime before renewal)

Installs timeout at 2Xk to send a new DHCP Request.
Installs timeout at X to delete address A
Installs timeout at 2X to delete address B
Installs timeout at 3X to delete address C

.
.
.

At X:
   Process timeout on address A:
      delete address A from interface
      delete address A from identity association record

At 2Xk:

Sends DHCP Request

Receives DHCP Reply:
   address B: lifetime = X
   address C: lifetime = 3X
   address D: lifetime = 2X

For each address in identity association record:
   deletes timeout for address
   is address in {B, C, D}?
     no: delete address from interface
	 delete address from identity association record
For each address in {B, C, D}:
   add timeout at address lifetime
   is address in identity association record?
     no: install address on interface
         install address in identity association record

This sounds kind of complicated, but I think it's significantly
simpler to implement than trying to come up with a mechanism for
renewing portions of the set of addresses in an identity association
seperately from other portions of that set.  And I don't think there's
any significant additional overhead - if you have to send a renewal
packet, you might as well renew all the addresses in the identity
association.   We'd have to think about this for the mobile phone
case (don't want a big packet), but I think it still works.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 23:42:02 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01655
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 23:42:02 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F3dLb27380;
	Thu, 14 Sep 2000 23:39:21 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F3dJb07122
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 23:39:19 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id D4BC227CC; Thu, 14 Sep 2000 22:39:03 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 67A6B1E15
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 22:39:03 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id XAA0000692582; Thu, 14 Sep 2000 23:38:57 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009150338.XAA0000692582@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Thu, 14 Sep 2000 13:09:14 EDT."
             <4.3.1.2.20000914111231.00b66a30@mail.bucknell.edu> 
Date: Thu, 14 Sep 2000 23:38:57 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ralph,

>Each IA is managed independently by the server and a client.  A client may 
>be an OS or an application and there may be multiple DHCP clients within a 
>single physical box.

I think we need some discussion on what multiple DHCP clients mean.

IPv6 Stateless will permit a DHCP Client to start.  

Can that Client spawn additional Clients or Client Processes or one
process each having its own client identifier?

For example if a node has 3 interfaces on the same link it will hear the
M bit three times from IPv6 stateless.  Each interface will be permitted
to request configuration parameters and addresses.

My first thought is I would like the freedom as implementor to have one
parent DHCP client and then spawn child clients or threaded clients each
with their own identifier hence IA's for each interface or two IA's for
one interface as Ted suggested in the con call.  This permits both #1
and #2 of Charlies model to DHCPv6 and IPng list too.

If that is what this can mean I support it if not we should clear it up.

>Servers control the IAs.  That is, a server determines the addresses 
>associated with an IA, perhaps based on hints from the client.  In 
>particular, the client does not get to "ask for three addresses".  I also 
>infer that the client does not get to ask for more addresses to be 
>associated with an existing IA.

So the server must know if the cliient is multihomed?

>IA identifiers may be structured to express a relationship between 
>clients.  E.g., identifiers from clients on the same computer might share a 
>common prefix.

But per Mark's mail we are not specifying this is my view?

>A client can make two requests to a server about an IA:

>* Associate some IP addresses with this IA
>* Renew this IA

Yes.

>The IP addresses associated with an IA have independent leases, which are 
>also independent of the IA renewal time.  Renewing an IA is independent of 
>extending the leases on the IP addresses associated with an IA.

Well we need some verbage if the client's Renewal IA expires before the
valid lifetime (the lease specifically) the client can still use the
address for existing connections, OR make it prohibitive in the spec
that renew of IAs cannot be less than the lease.

>Jim noted that "leases" may not be appropriate for IPv6 addresses, as an 
>IPv6 address is either valid or invalid.  While valid, an address may be 
>preferred or deprecated.  From RFC 2462, "IPv6 Stateless Address 

I did not mean to imply the word lease is inappropriate.  What I stated
is that DHCPv6 must pass the client both a valid and preferred lifetime.
If we want to define that combination as a lease that is fine.

>In any event, does this summary capture the consensus on the address model?

Except for my questions above for me they do.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep 14 23:54:38 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01787
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 14 Sep 2000 23:54:38 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F3sHb28153;
	Thu, 14 Sep 2000 23:54:17 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F3sAb26247
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 23:54:10 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 866EE3E13; Thu, 14 Sep 2000 23:53:55 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id 245F03F78
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 23:53:55 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id XAA0000694066; Thu, 14 Sep 2000 23:53:53 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009150353.XAA0000694066@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 client identification... 
In-reply-to: Your message of "Thu, 14 Sep 2000 14:20:38 EDT."
             <4.3.1.2.20000914141239.00b6c2e0@mail.bucknell.edu> 
Date: Thu, 14 Sep 2000 23:53:51 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ralph,

>>Also, if applications are going to be requesting addresses (we're all
>>assuming this, aren't we?),

I heard in the design meeting and often WG members want this to be a
capability of the protocol.  And from the IPng WG.

>I need to remind us here that we have not firmly established a need for 
>applications to request addresses.  We've decided that the example of 
>multiple web services on a single host does not require 
>application-specific IPv6 addresses (based on recent versions of 
>HTTP).  We've also heard that the model of applications requesting 
>addresses is not currently under consideration anywhere else in the IPv6 
>spec development community.
>
>We need to assess the current spec and proposals to determine if there is 
>complexity in the spec that can be attribute solely to supporting 
>application requests for addresses; if so, we need to understand that 
>complexity and decide whether the complexity is worth the benefit of the 
>additional function.

I agree we need to make that assessment.  How we do that is an important
thread.  I as you know do not think the above is a strong argument to
not permit this we defined many things in IPv6 that we are just now
being able to use like scoped addresses and we still are working on the
flowlabel as two examples.

But I think also we are architecting the stateful counterpart to the
IPv6 stateless mechanism in IPv6.  Hence, I re send Charlies mail of
late again and think very appropriate as input to this discussion.

regards,
/jim

Return-Path: charliep@iprg.nokia.com
Received: from oflume.zk3.dec.com by iota.zk3.dec.com (8.7.6/UNX 1.7/1.1.20.3/24Apr98-0811AM)
	id RAA0000011466; Wed, 30 Aug 2000 17:44:43 -0400 (EDT)
Received: from zmamail01.zma.compaq.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM)
	id RAA0000011402; Wed, 30 Aug 2000 17:44:42 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 6CE9B2313; Wed, 30 Aug 2000 17:44:12 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id E80D358E5
	for <bound@zk3.dec.com>; Wed, 30 Aug 2000 17:44:11 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA05809;
	Wed, 30 Aug 2000 14:44:11 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e7ULi7D07775;
	Wed, 30 Aug 2000 14:44:07 -0700
X-Virus-Scanned:  Wed, 30 Aug 2000 14:44:07 -0700 Nokia Silicon Valley Email Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpd7hVwVX; Wed, 30 Aug 2000 14:44:03 PDT
Sender: charliep@iprg.nokia.com
Message-ID: <39AD8026.4395DF11@iprg.nokia.com>
Date: Wed, 30 Aug 2000 14:44:06 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: IPng Working Group <ipng@sunroof.eng.sun.com>
Cc: dhcp-v6@bucknell.edu, Jim Bound <bound@zk3.dec.com>,
        Mike Carney <Michael.Carney@eng.sun.com>
Subject: Reasons for dynamic IPv6 address allocation for DHCPv6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hello folks,

Some people on the new DHCPv6 design team seem to be taking the
viewpoint that managed IPv6 computers are going to be like desktops.
>From that perspective, it's O.K. to revise the server's centralized
IP address allocation policy and reboot the IPv6 computer whenever
one needs a new IP address for some reason.  Perhaps an exception
will be made to allow network prefix renumbering to occur without
rebooting.

However, it seems quite likely that the future Internet will
have a lot of highly configurable and mobile devices, for which
the current static address configuration schemes being suggested
will be inadequate.

Some of the problem seems to stem from current preference of
configuring all necessary client parameters at reboot time.
What happens when the DHCPv6 client wants to run a synchronized
application, and the server didn't give out the timeserver extension
when the client rebooted?

Why do we have to frame all application requirements in terms of
what happens when the client reboots?

This was a design goal for DHCPv6 -- to avoid tying all application
needs to boot-time configuration.  I am afraid that we're going back to
boot-time constraints.  It's a dark place, not healthy for mobile nodes.

Regarding address allocation, the choices (as I understand them),
are as follows:

1) Each computer will get an IPv6 address whenever it asks for
   it.  If it asks twice, it will get two addresses.

2) Each computer will get the same list of IPv6 addresses no
   matter how often it asks.

I _think_ that the proponents of (2) will require editing the
server database before a DHCPv6 client could get another (new) 
address.  This is being suggested as a matter of "simplicity".

As a strong proponent of (1), and by the way as a strong proponent
of highly reconfigurable embedded devices, I find this is a big 
step backwards from the existing DHCPv6 specification.

Please note that any installation which favors (2) can trivially
implement the appropriate policy even in the existing DHCPv6
specification.  The discussion is not whether (2) is a useful
model for network administration.  No one disputes that (2)
should be enabled by DHCPv6.  No, instead, the discussion is
whether (1) should even be allowed at all.  The proponents of
the supposed (in my opinion quite illusory) gain in simplicity
wish to control address allocation policy to the extent that  
that DHCPv6 clients can never deviate from the pre-ordained
list of addresses.  Perhaps it will be "allowed" for clients
to spoof new identities by representing themselves using new
client identifiers. 

I offer a possible look at future address allocation policy. 
This is, of course, speculative, given that we have not
evolved into the world of plentiful IPv6 addresses yet.

First, I point out that anonymous addresses should (typically)
be acquired and used once, by a single application, and not 
necessarily used again.  Any policy by which a host computer
is allocated a list of "anonymous addresses" by a DHCPv6 server,
and gets the same list over and over again, is slightly cracked,
again in my opinion.  Designing a whole new DHCPv6 address allocation
protocol for anonymous addresses certainly argues against any
supposed gain in "simplicity".  I think it is very likely that
anonymous addresses on administered links have to be requested by
the application at the time of execution, and not preallocated.
Furthermore, any such address should be returned once it has  
been used (thus it is a "releasable resource"), or else requested
with a short lifetime.

DHCPv6 will likely be used to provide IPv6 care-of addresses on
administered links.  A mobile node may need to get a care-of
address for each of its IPv6 home addresses, but we do not know
enough to suppose that it always has to get a care-of address
for each of its home addresses.  It may use the same care-of 
address for more than one home address, or it may not.  Sometimes
it will want to get a care-of address for only one of its addresses,
or two, or four, even if it might have 10 home addresses.  For
such a node to be constrained _by DHCPv6 protocol_ to always  
getting all of its care-of addresses from the server is highly
suspect, and (worse) may imply some sort of preconfiguration
of each mobile device at the DHCPv6 server.

These are examples that are known today.  In the future, there
will be more.  I almost hate to go into description, because 
after all the strife in DHCPv6 it could be I will be attacked as
a dreamer who just does not understand existing practice.  But 
damn the torpedoes and here I go.  We do not _know_ all the ways
that IPv6 addresses will be used.

During this discussion, please keep in mind that future applications
should be able to be dynamically loaded onto a host computer at any
time.  While many computers may not support such features, many
other computers will.  We should not have to design _two_ protocols
for the different kinds of computers that use IPv6 addresses.

I believe that IPv6 addresses will continue to embody a certain  
amount of context and identity (on behalf of the user).  Thus,
if an application wishes to create a separate context and avoid
association with another application running on the same network
node, the most natural thing will be for that application to  
configure a new IPv6 address.  If the link is a managed link, then
DHCPv6 has to provide for that.

Each new (or sporadically used) identity may have special features:
- security profile
- QoS 
- special routing requirements (e.g. routing header)
- remote profile management 
- separate billing

It's not the job of the network layer feature configuration
architect to limit these future choices.

Thus, I claim that the direction, which has been very strongly
encouraged by several DHCPv4 experts, towards eliminating IPv6
address configuration flexibility, is wrong.  I hope that this
note to the IPng working group will serve to raise the level of
discussion so that the impending disaster can be averted.

Lastly, I will mention that we can't tell the applications exactly
how they ought to call DHCPv6 in order to get new addresses,
because no one has yet designed the API.  However, it would
take a lot longer to get the API right, judging from the history
of other APIs in the IPng group.  That should not be a precondition
for getting the protocol ready for initial deployment.

Regards,
Charlie P.

- Ralph



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 00:14:37 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01932
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 00:14:37 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F4CFb03263;
	Fri, 15 Sep 2000 00:12:15 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F4C5b14655
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 00:12:05 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id 2DCB43E86; Thu, 14 Sep 2000 23:11:50 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id A61192AB5
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 23:11:49 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id AAA0000695651; Fri, 15 Sep 2000 00:11:47 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009150411.AAA0000695651@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 Relay Changes 
In-reply-to: Your message of "Thu, 14 Sep 2000 15:01:34 EDT."
             <4.3.1.2.20000914150033.00b59e00@mail.bucknell.edu> 
Date: Fri, 15 Sep 2000 00:11:46 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>>Is this really encapsulation?
>>
>>or
>>
>>A new relay extension msg type to encapsulate client solicits and
>>requests.
>>
>>At the design meeting I was thinking real encapsulation.

>I was imagining a new message extension type that carries the client 
>message in another DHCP message between the relay and the server.

Real encapsulation eliminates any new security for the payload.
A new extension changes the payload and the security mechanisms would
have to be rehashed or whatever.

How do we resolve this.

But either way we can avoid nested encapsualtion is my strong
suggestion.  Another way to do it is that relays set the IPv6 HOP-BY-HOP
option and say don't look at this just forward it.

regards,
/jim

- Ralph



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 00:21:01 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01980
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 00:21:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F4Kgb00282;
	Fri, 15 Sep 2000 00:20:42 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F4KZb29077
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 00:20:35 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id EF1DE2A4C; Thu, 14 Sep 2000 23:20:19 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 4EE613E34
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 23:20:19 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id AAA0000695935; Fri, 15 Sep 2000 00:20:17 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009150420.AAA0000695935@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Thu, 14 Sep 2000 15:31:09 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC158@lespaul.process.com> 
Date: Fri, 15 Sep 2000 00:20:15 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>- I believe we all agreed that allowing the client to supply a list of
>prefixes for addresses the client wanted is allowed. The server can supply
>additional addresses and might not assign addresses for all supplied
>prefixes.

I believe we all agreed to this to?  

>- I believe the renewal was a bigger issue because it wasn't clear whether a
>client could "renew" an individual address or had to renew all of them. The
>issue also required us to resolve whether lifetimes are per address or per
>IA, which was never fully resolved. As with router prefix advertisements, I
>personnally feel that the lifetimes should be per address, not per IA (ie,
>the "lease" each address includes per address lifetimes, rather than a
>single lifetime for all addresses).

Leases are for Addresses not IAs.  IAs are only identifiers that is
all.

>The way the list of requests below reads ("renew this IA") kind of implies
>that one leases IAs and not addresses. Perhaps you've implied to solve the
>problem by saying all addresses for an IA have the same lifetimes?

This also removes the capability for a sever admin to give one address
it provides a client one lifetime and another address for a client a
different lifetime.

The other reason we need to have lifetimes per addresses is for
dynamic renumbering with DHCPv6.  After a reconfigure-init the server
can reduce the lifetimes of one of the addresses but extend or keep the
others to gradually fade out that particular address.  This is a feature
the current design supports that is important for one of the goals of
IPv6 to support dynmamic renumbering and one of IPng's goals in the
IETF. And dynamic renumbering is the key reason for reconfigure-init.

It seems we need to discuss this further.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 00:28:21 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02043
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 00:28:21 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F4S2b30534;
	Fri, 15 Sep 2000 00:28:02 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F4Rtb03884
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 00:27:55 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 9A3D83C0E; Fri, 15 Sep 2000 00:27:40 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id 7D5CB3E0D
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 00:27:40 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id AAA0000696824; Fri, 15 Sep 2000 00:27:38 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009150427.AAA0000696824@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: bound@ZK3.DEC.COM
Subject: Re: Design team teleconference, 8/31 
In-reply-to: Your message of "Thu, 14 Sep 2000 15:32:35 EDT."
             <4.3.1.2.20000914152733.00b15700@mail.bucknell.edu> 
Date: Fri, 15 Sep 2000 00:27:36 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>>   The current DHCPv6 message names
>>correspond directly to Neighbor Discovery rfc 2462 thats where they came
>>from.  I think it more important to stay in synch with that part of IPv6
>>than DHCPv4.
>
>If the messages are really different messages - with different semantics - 
>then sure, we should go with RFC 2462.  If the DHCPv6 messages walk and 
>quack like DISCOVER/OFFER/REQUEST/ACK then that's what we oughta call 'em...

But they don't look like them at all or even remotely resemble them at
all.  Or the behavior affect of the server from the messages.

One example is that in DHCPv4 the server awaits after the OFFER to hear
back.  In DHCPv6 now the server has to keep no state after the
advertize.  I think thats a better model than DHCPv4 and servers don't
have to keep state the advertize in DHCPv6 is stateless.

Also the DHCPv6 client code will live in very close proximity to the
stateless client if you will for IPv6 addrconf.  The message names in
DHCPv6 correspond to the syntax of ND.  So one can have:

nd_solicit
dhc_solicit
nd_advertise
dhc_advertise

so one could actually write one client to do both and thread/fork/spawn
the necessary processes to handle stateless or multiple client IAs.

I can go on but I think we need more WG discussion.

regards,
/jim

- Ralph



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 00:33:44 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02119
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 00:33:44 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F4WMb31972;
	Fri, 15 Sep 2000 00:32:22 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F4W9b06183
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 00:32:09 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 7B9512796; Thu, 14 Sep 2000 23:31:54 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id EB06E27C4
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 23:31:53 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id AAA0000697425; Fri, 15 Sep 2000 00:31:47 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009150431.AAA0000697425@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 Relay Changes 
In-reply-to: Your message of "Thu, 14 Sep 2000 15:35:20 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC159@lespaul.process.com> 
Date: Fri, 15 Sep 2000 00:31:46 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>I don't believe we want to do IP layer encapsulation since the DHCP relay
>agent has typically run above the IP layer (above UDP) and I don't think we
>want to change that. Especially when you consider the kinds of things that
>Relay Agents might be doing these days (CMTS devices). Keeping relay agents
>at the application layer is the right thing to do.

Hmm?  I have lots of code that knows nothing about the kernel that does
encap and decap.  Also lots of VPNs are built in user space and one just
sets up the routing table correctly.  No big deal.

More importantly what is wrong with the way dhcpv4 and dhcpv6 do it
today again?

regards,
/jim 



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 00:57:08 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02262
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 00:57:08 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F4sMb09604;
	Fri, 15 Sep 2000 00:54:22 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F4sLb30101
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 00:54:21 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id 331EC12BE; Thu, 14 Sep 2000 23:54:01 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id B438F3CAC
	for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 23:54:00 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id AAA0000699164; Fri, 15 Sep 2000 00:53:58 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009150453.AAA0000699164@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: bound@ZK3.DEC.COM
Subject: Re: Design team teleconference, 8/31 
In-reply-to: Your message of "Thu, 14 Sep 2000 16:55:55 EDT."
             <Pine.GSO.4.03.10009141652540.20956-100000@leo> 
Date: Fri, 15 Sep 2000 00:53:56 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ralph,

>> While I agree with Ralph's reasoning for using the DHCPv4 messages, I do
>> believe that we should use different names because:
>> - The message formats are no where near close

>I claim the message formats aren't important in this context.  A
>pretty-printer can make them look the same when snooping packets...

Bernie and I said the messages are not even close in context?

Why is that not convincing?  

>> - The behavior of the protocol (and what the messages cause to occur and
>> communicate) is different in significant ways

I think I did and so did Bernie?  Can you respond to that part of the
mail too so I can understand why you don't think it applies.

>I don't believe that we've shown that the messages *must* have different
>semantics.  I gave two examples of how Solicit/DHCPDISCOVER and
>Advertise/DHCPOFFER have come to have quite similar semantics.  I'd like
>to see a convincing argument that the remaining differences are important
>to the operation of DHCPng.

I don't believe you or anyone has shown a compelling reason to change
the existing names.   Maybe I missed it in the mail.  
I have countered and so has Bernie your statements above that the
semantics are different and also affect the servers differently?

I think we are at a crossroad.  I believe we have show cases wher e the
messages are not the same at all.  

In fact I think solicit is more appropriate than the word discover.

They have been in the specs as words for a long time.  I don't think
you have shown a compelling strategic or technical reason to change
them?  

regards,
/jim

- Ralph



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 01:03:00 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02338
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 01:03:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F52eb25926;
	Fri, 15 Sep 2000 01:02:40 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F52cb08828
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 01:02:38 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 287C715F7; Fri, 15 Sep 2000 01:02:23 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id E09B514E0
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 01:02:22 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id BAA0000700426; Fri, 15 Sep 2000 01:02:19 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009150502.BAA0000700426@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 Relay Changes 
In-reply-to: Your message of "Thu, 14 Sep 2000 14:13:32 PDT."
             <200009142113.e8ELDW021912@grosse.bisbee.fugue.com> 
Date: Fri, 15 Sep 2000 01:02:18 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>Right, that was what I was thinking too - that's why I suggested
>encapsulating the client's entire message in a DHCPv6 extension of a
>new DHCP Relay message.   The relay agent can then optionally sign the
>message or include additional information.

If we do this then that will work.  I did not get this out of Barr's
message but this will work I agree.

I would argue encapsulation is the wrong word but append is the correct
term.

IPv6 Header
UDP
-->DHCPv6 New Extension Relay Msg
----> Original DHCPv6 Msg Header + Data

You could simply say following this extension exists the orginal message
and then the server does not have to deal with decap or encap.

If the relay puts the server address in the IPv6 DST addr which it
should there will be no more need for any encap operation.

If the relay puts another relay in the IPv6 header in the DST address
which I think we should disallow then the best way to do this would be
to use the IPv6 Route Option and put the servers address in the Routing
option.

But we should design this so nested levels are not required.  I think
that can be done.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 01:09:53 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03068
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 01:09:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F59Zb08853;
	Fri, 15 Sep 2000 01:09:35 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F59Lb08614
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 01:09:21 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 5E64D1FBB; Fri, 15 Sep 2000 00:09:06 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id E581C24FA
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 00:09:05 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id BAA0000700666; Fri, 15 Sep 2000 01:09:03 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009150509.BAA0000700666@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Design team teleconference, 8/31 
In-reply-to: Your message of "Thu, 14 Sep 2000 14:24:25 PDT."
             <200009142124.e8ELOP022091@grosse.bisbee.fugue.com> 
Date: Fri, 15 Sep 2000 01:09:01 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>> I'd like to see a convincing argument that the remaining differences
>> are important to the operation of DHCPng.
>
>I don't think they are.   I don't mind the new semantics, and I think
>they make sense, but the old semantics make sense too.   I think that
>with the additional addressing complexity of DHCPng, the old semantics
>probably aren't as useful, but that doesn't mean we *have* to get rid
>of them.

The design minutes state DHCPng is for the future.  But we want to try
to not do anything that will prohibit a ***future*** DHCPng.  But what
my impression is that what we are working on here is DHCPv6.

I see no reason why the existing message names are not appropriate. The
existing messages do different functions than DHCPv4 but can support
DHCPv4.  I claim the reverse is not true for DHCPv4 messages and have
sent other mail why syntactically the existing messages are better and
open to hearing why I am wrong and on the other mail.

In fact I think we have this backwards.  Proponents of changing the
message names should be defending their change not the current names.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 01:35:53 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06818
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 01:35:52 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F5XXb12316;
	Fri, 15 Sep 2000 01:33:33 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F5XMb15664
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 01:33:22 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-211.ip.theriver.com [206.97.58.211]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id EAA13997 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 04:39:49 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8F5UH028199 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 22:30:18 -0700 (MST)
Message-Id: <200009150530.e8F5UH028199@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 Relay Changes 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Fri, 15 Sep 2000 00:11:46 -0400." <200009150411.AAA0000695651@anw.zk3.dec.com> 
Date: Thu, 14 Sep 2000 22:30:17 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Real encapsulation eliminates any new security for the payload.
> A new extension changes the payload and the security mechanisms would
> have to be rehashed or whatever.

Both kinds of encapsulation being discussed here are real.  Nobody is
proposing a BOOTP-style operation where the relay agent modifies the
contents of the payload from the client.  It sounds like you're
proposing IP-in-IP encapsulation, but that can't work, because
IP-in-IP encapsulation doesn't allow the relay agent to add its
information to the payload - only to the header.

A very large portion of the DHCP application space is the cable
modem/DSL provider who very much wants the relay agent to add
additional payload that *can't* go in the IP header - information
about the cable modem head end system, the remote site id, and stuff
like that.   In DHCPv4 we use the relay agent information option, but
this is really ugly - we're only doing it because we have to.

We can't use IPsec for DHCPng, because of the chicken-and-egg startup
problem, so we're not losing anything by not using IP-in-IP
encapsulation.   The relay agent actually *could* use IPsec to the
server, since *it* can establish a security association with the
server, but its IPsec would sign its packet and the entire payload -
the signature on the DHCP client's packet would not be in the header,
and therefore would not be lost.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 01:37:31 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06995
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 01:37:31 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F5acb09595;
	Fri, 15 Sep 2000 01:36:38 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F5aRb11731
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 01:36:28 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-211.ip.theriver.com [206.97.58.211]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id EAA14009 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 04:42:56 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8F5XO028254 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 22:33:24 -0700 (MST)
Message-Id: <200009150533.e8F5XO028254@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 Relay Changes 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Fri, 15 Sep 2000 01:02:18 -0400." <200009150502.BAA0000700426@anw.zk3.dec.com> 
Date: Thu, 14 Sep 2000 22:33:24 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> If we do this then that will work.  I did not get this out of Barr's
> message but this will work I agree.
> 
> I would argue encapsulation is the wrong word but append is the correct
> term.

IP-in-IP encapsulation is wrong.   Append is also wrong, though.   We
really are encapsulating it, not appending some stuff onto the end, or
appending it to the end of some stuff.   At least, I'd rather do it
that way - it makes things more explicit, and thus (IMHO) easier to
specify.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 01:44:24 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07966
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 01:44:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F5i7b20962;
	Fri, 15 Sep 2000 01:44:07 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F5i1b10983
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 01:44:01 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-211.ip.theriver.com [206.97.58.211]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id EAA14023 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 04:50:29 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8F5ev028347 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 22:40:57 -0700 (MST)
Message-Id: <200009150540.e8F5ev028347@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Design team teleconference, 8/31 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Fri, 15 Sep 2000 01:09:01 -0400." <200009150509.BAA0000700666@anw.zk3.dec.com> 
Date: Thu, 14 Sep 2000 22:40:57 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


The advantage of DHCPDISCOVER/DHCPOFFER is that the DHCPDISCOVER
message asks for an IP address, and DHCPOFFER can say "this is the
address I will give you if you pick me."  DHCPsolicit/DHCPadvertise
doesn't provide this functionality.  I think that this is useful
functionality, and I am loath to give it up.

I can see why you like your new way of doing things, but there is
definitely a good reason to continue with the old method, or at least
so it seems to me.  Is this a strong enough reason to go back?   I
can't say.   In my mind it is.   It sounds like Ralph agrees.   I'd be
interested in seeing if anybody else wants to weigh in on the issue.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 02:00:48 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10001
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 02:00:48 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F603b16945;
	Fri, 15 Sep 2000 02:00:03 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F5xpb08830
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 01:59:51 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id A68A524E2; Fri, 15 Sep 2000 00:59:35 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id DCA92278B
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 00:59:34 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id BAA0000707255; Fri, 15 Sep 2000 01:59:33 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009150559.BAA0000707255@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Thu, 14 Sep 2000 15:44:56 PDT."
             <200009142244.e8EMiu023074@grosse.bisbee.fugue.com> 
Date: Fri, 15 Sep 2000 01:59:32 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>I think the solution to the problem is that each address should have
>its own lifetime, but that the identity association should have a
>renewal time.  If the DHCP server isn't going to renew a deprecated
>address, it can set the identity association renewal time to be after
>the lifetime of that address expires.  Excluding deprecated addresses,
>the DHCP server would then use the shortest lifetime of the remaining
>addresses to figure the lease time for the identity association.   The
>DHCP client would then always renew at the appropriate percentage of
>the identity association renewal time.

I think this would work for first spec attempt...

Don't you mean the "DHCP sever would then use the "longest" lifetime...?

We don't want the identity assoication expiring before address
lifetimes that will cause big problems.

>So what I'm suggesting is that we seperate out the lifetime concept
>from the renewal time concept.  The client tracks lifetimes in the
>sense that if an address's lifetime expires, the client drops it.  But
>it always renews identity associations, not address lifetimes.  So on
>the client side you have a drop dead timer on each lifetime that's
>initialized each time an address is installed as a result of the
>server assigning it.  The client also has to remember that each of
>these addresses is part of an identity association, and drop the
>addresses if the server doesn't renew them.  But in terms of asking
>for renewals, it renews all the addresses associated with an IA at
>once, even if some of them have much longer lifetimes than others.

I think this is causing extra packets on a network.

Lets suppose a client has 4 128bit IPv6 address and thats also 8 32bit
lifetimes.

All but one valid lifetime for one address are 10 hours.  But this one
address is 1 hour.   I don't think the client should have to send all 4
addreses across the wire to get one either more time or not more time.

>The implementation looks something like this (I've simplified the
>initial DHCP Reply processing - really, both DHCP Replies are
>processed as in the description of the second DHCP Reply):

>Receives DHCP Reply:
>   address A: lifetime = X (deprecated)

What is the notation (deprecated) mean?

>   address B: lifetime = 2X
>   address C: lifetime = 3X
>   renewal time: 2Xk (k = percentage of lease lifetime before renewal)

In DHCPv6 two lifetimes are sent as a note.  Valid and Preferred.
So in your model I assume the times are the Valid Lifetimes.

Why not make renewal time: 3Xk (I am assuming X is some constant right)

>Installs timeout at 2Xk to send a new DHCP Request.
>Installs timeout at X to delete address A
>Installs timeout at 2X to delete address B
>Installs timeout at 3X to delete address C

I don't think 3X should be running during renewal state.

I also think X should not have to wait for Request at renewal state.
But that implies we need more discussion for IA if it changes.

.
.
.

>At X:
>   Process timeout on address A:
>      delete address A from interface
>      delete address A from identity association record

>At 2Xk:

>Sends DHCP Request

>Receives DHCP Reply:
>   address B: lifetime = X
>   address C: lifetime = 3X
>   address D: lifetime = 2X

I don't agree with this.  What if the server is providing A as the nodes
global address to reach the Intratnet to the Internet and the others are
site local addresses.  The server wants the client to check back in for
global addresses not loose them after getting them once.  

>For each address in identity association record:
>   deletes timeout for address
>   is address in {B, C, D}?
>     no: delete address from interface
>	 delete address from identity association record
>For each address in {B, C, D}:
>   add timeout at address lifetime
>   is address in identity association record?
>     no: install address on interface
>         install address in identity association record

>This sounds kind of complicated, but I think it's significantly
>simpler to implement than trying to come up with a mechanism for
>renewing portions of the set of addresses in an identity association
>seperately from other portions of that set.  And I don't think there's
>any significant additional overhead - if you have to send a renewal
>packet, you might as well renew all the addresses in the identity
>association.   We'd have to think about this for the mobile phone
>case (don't want a big packet), but I think it still works.

I don't agree. Francis has implemented the model to permit a client to
renew a specific address and we have just done it for our Infiniband
work in Compaq using solicit, request, and reply.  So I now declare that
is another implementation in addition to Francis's. 

Also I am thinking we should not tie the REQUEST to the renewal time for
the IA.  The IA is the binding for the client with some other cruft we
need to figure out as implementors.  If that changes lots changes and
including the reason we are using the IA for security keys.

Here is my implementation:

address A valid lifetime == X preferred lifetime == Y
address B valid lifetime == 2X preferred lifetime == 2Y
address C valid lifetime == 3X preferred lifetime == 3Y
renewal IA lifetime == >3Xk (same k constant as yours)

Address A
   at 80% Y
   if A will not be RELEASED by Client (mobile node decision)
                                       (for handoff as example using
                                        lazy cell evaluation)
      REQUEST address A again

Address B 
   at 80% 2Y 
   if B will not be RELEASED by Client (mobile node decision)
                                       (for handoff as example using
                                        lazy cell evaluation)
     REQUEST address B again

ditto for C

Renewal Timer for IA goes off:
     REQUEST (no addresses supplied just like the client is
              in start state after advertise message)

Note I think the IA needs its own message type too to negotiate a new
IA with the Server as it changes the bindings at the server and I assume
the security keys.

We want to permit clients to continue use if they want an address
before the deprecated state which is when the preferred timers goes off
per IPv6 addr conf.

At server

Recv REQUEST 
Locate Clients IA+cruft BINDING
 if addresses in REQUEST
  renew lifetimes on address or address set provided for which the
     server previously supplied the client
 else
  provide client all addresses it is permitted to have at this point
     in time (note "time" is key here as the server can change that)
  
The above is completely idempotent (and reentrant) as long as any
changes to the IA are not done at this state.  That should be another
state I don't think we started discussing yet.

The above depicts the advantage of Ted's IA over the current DHCPv6
model.  We still permit the server to maintain tight control over a
finite set of addresses and the client can request no more than the 
server provided.  This is what Ralph wanted I think.

But if the client wants to request more addresses for an interface or a
link or even an NBMA PVC connection they can set up a new IA and then
send REQUEST to the server and the implementation above still works and
can be its own module and thread on the server for all cases.  This
supports what Charlie wanted.

We get both models in our spec.

regards,
/jim 



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 02:36:13 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15436
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 02:36:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F6Xpb20902;
	Fri, 15 Sep 2000 02:33:51 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F6Xgb17612
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 02:33:42 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 08EF124DB; Fri, 15 Sep 2000 01:33:27 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 82E1E24CA
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 01:33:26 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id CAA0000710546; Fri, 15 Sep 2000 02:33:24 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009150633.CAA0000710546@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 Relay Changes 
In-reply-to: Your message of "Thu, 14 Sep 2000 22:30:17 PDT."
             <200009150530.e8F5UH028199@grosse.bisbee.fugue.com> 
Date: Fri, 15 Sep 2000 02:33:24 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>> Real encapsulation eliminates any new security for the payload.
>> A new extension changes the payload and the security mechanisms would
>> have to be rehashed or whatever.

>Both kinds of encapsulation being discussed here are real.  Nobody is
>proposing a BOOTP-style operation where the relay agent modifies the
>contents of the payload from the client.  It sounds like you're
>proposing IP-in-IP encapsulation, but that can't work, because
>IP-in-IP encapsulation doesn't allow the relay agent to add its
>information to the payload - only to the header.

Not proposing anything yet.  Just discussing.  But yes IP-in-IP.

Sure it will.  We just have UDP and the extension barr proposed within
the outer IP.  That will work for sure.  I have made it work a long time
ago when dhcpv6 was I think 19 pages.   A long time ago.  Also IPsec
(not saying use that OK) will work too.  The trick is that you now need
security associations btw the relay and server.

You would have to deliver two UDP packets to the server and what I don't
like about it.

>A very large portion of the DHCP application space is the cable
>modem/DSL provider who very much wants the relay agent to add
>additional payload that *can't* go in the IP header - information
>about the cable modem head end system, the remote site id, and stuff
>like that.   In DHCPv4 we use the relay agent information option, but
>this is really ugly - we're only doing it because we have to.

Good input.

>We can't use IPsec for DHCPng, because of the chicken-and-egg startup
>problem, so we're not losing anything by not using IP-in-IP
>encapsulation.   The relay agent actually *could* use IPsec to the
>server, since *it* can establish a security association with the
>server, but its IPsec would sign its packet and the entire payload -
>the signature on the DHCP client's packet would not be in the header,
>and therefore would not be lost.

Not proposing IPsec but I will say for the record dhcpv6 should do
nothing to prevent using IPsec and I don't believe we did in the current
design.

The market will decide security mechanisms not us.

regards,
/jim

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 02:38:49 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15458
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 02:38:49 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F6Zib22750;
	Fri, 15 Sep 2000 02:35:44 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F6Zdb13829
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 02:35:39 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id 7728C2AC8; Fri, 15 Sep 2000 01:35:24 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 2E5E02B9B
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 01:35:24 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id CAA0000710461; Fri, 15 Sep 2000 02:35:22 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009150635.CAA0000710461@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 Relay Changes 
In-reply-to: Your message of "Thu, 14 Sep 2000 22:33:24 PDT."
             <200009150533.e8F5XO028254@grosse.bisbee.fugue.com> 
Date: Fri, 15 Sep 2000 02:35:21 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>> If we do this then that will work.  I did not get this out of Barr's
>> message but this will work I agree.
>> 
>> I would argue encapsulation is the wrong word but append is the correct
>> term.

>IP-in-IP encapsulation is wrong.   Append is also wrong, though.   We
>really are encapsulating it, not appending some stuff onto the end, or
>appending it to the end of some stuff.   At least, I'd rather do it
>that way - it makes things more explicit, and thus (IMHO) easier to
>specify.

I don't agree with you.  Lets hear from others I will support consensus.

regards,
/jim 



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 02:42:40 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15478
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 02:42:40 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F6gGb21522;
	Fri, 15 Sep 2000 02:42:16 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F6g5b21138
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 02:42:05 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id AB4032BC0; Fri, 15 Sep 2000 01:41:49 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 456D410EB
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 01:41:48 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id CAA0000711386; Fri, 15 Sep 2000 02:41:46 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009150641.CAA0000711386@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Design team teleconference, 8/31 
In-reply-to: Your message of "Thu, 14 Sep 2000 22:40:57 PDT."
             <200009150540.e8F5ev028347@grosse.bisbee.fugue.com> 
Date: Fri, 15 Sep 2000 02:41:45 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>The advantage of DHCPDISCOVER/DHCPOFFER is that the DHCPDISCOVER
>message asks for an IP address, and DHCPOFFER can say "this is the
>address I will give you if you pick me."  DHCPsolicit/DHCPadvertise
>doesn't provide this functionality.  I think that this is useful
>functionality, and I am loath to give it up.

Not quite.  Advertise permits one to give the client addresses too with
extensions.

But presently we also require that a request must then be done.

>I can see why you like your new way of doing things, but there is
>definitely a good reason to continue with the old method, or at least
>so it seems to me.  Is this a strong enough reason to go back?   I
>can't say.   In my mind it is.   It sounds like Ralph agrees.   I'd be
>interested in seeing if anybody else wants to weigh in on the issue.

Not my new way.  I had initially solicit and request and reply really
simple stuff.  THe model today currently was the WGs the past 3 years.
Not mine.  I think we need a fast commit esp for mobile nodes.  I think
the advertise can support that.  But thats another thread.

I agree need others to weigh in.  Also its not just me its Bernie and
me on keeping existing names.

Others???

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 02:43:05 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15489
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 02:43:04 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F6gYb25872;
	Fri, 15 Sep 2000 02:42:34 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F6gJb13918
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 02:42:19 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-211.ip.theriver.com [206.97.58.211]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id FAA14133 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 05:48:45 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8F6d8029024 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 23:39:09 -0700 (MST)
Message-Id: <200009150639.e8F6d8029024@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Fri, 15 Sep 2000 01:59:32 -0400." <200009150559.BAA0000707255@anw.zk3.dec.com> 
Date: Thu, 14 Sep 2000 23:39:08 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> We don't want the identity assoication expiring before address
> lifetimes that will cause big problems.

It's not an expiry time.  It's a renewal time.  This allows us to
renew all addresses in an identity association at the same time,
rather than having each address's renewal come at a different time.
The addresses do not expire until their lifetimes expire.

> All but one valid lifetime for one address are 10 hours.  But this one
> address is 1 hour.   I don't think the client should have to send all 4
> addreses across the wire to get one either more time or not more time.

Yes, this could result in more bits passing across the wire in cases
where the disparity between renewal times is very large.  But it would
result in the same number of packets, so this would matter only in a
context where indivual bits in a packet really count.  And I think
this is actually a very unlikely scenario - can you come up with a
reason why the lifetimes would be so different?

> >   address B: lifetime = 2X
> >   address C: lifetime = 3X
> >   renewal time: 2Xk (k = percentage of lease lifetime before renewal)
> 
> In DHCPv6 two lifetimes are sent as a note.  Valid and Preferred.
> So in your model I assume the times are the Valid Lifetimes.

That's an interesting topic for discussion.   I can see good reasons
for using either one.

> Why not make renewal time: 3Xk (I am assuming X is some constant right)

X is a constant in the sense of a convenience constant in algebra, not
something predefined by the server.   I could have said "10, 20 and
30".   The point is just to establish a size relationship between the
lifetimes of the leases.   I would expect X to be some number of
hours, and k to be .8.   I should have been more explicit here - sorry
about that.   But you used "idempotent" in your message, so you don't
get to complain!   :')

Anyway, in this case, 3Xk is greater than 2X, so address B will expire
before the client renews, which probably isn't what you want - you
want to renew address B *before* it expires.  So the renewal time has
to be 2Xk, not 3Xk.

> >Installs timeout at 2Xk to send a new DHCP Request.
> >Installs timeout at X to delete address A
> >Installs timeout at 2X to delete address B
> >Installs timeout at 3X to delete address C
> 
> I don't think 3X should be running during renewal state.
> 
> I also think X should not have to wait for Request at renewal state.
> But that implies we need more discussion for IA if it changes.

All of the above timeouts are installed at the same time.

> I don't agree with this.  What if the server is providing A as the nodes
> global address to reach the Intratnet to the Internet and the others are
> site local addresses.  The server wants the client to check back in for
> global addresses not loose them after getting them once.  

The scenario here is that address A is deprecated, and will not be
renewed.   If address A is not deprecated, then it will be counted by
the server in determining the renewal time, and so the renewal time
will be Xk, not 2Xk.

> Address A
>    at 80% Y
>    if A will not be RELEASED by Client (mobile node decision)
>                                        (for handoff as example using
>                                         lazy cell evaluation)
>       REQUEST address A again

Address A is deprecated, meaning that the server will not extend it,
so a request at this time would be met with a renewal for 20% Y, and
then the new renewal time would be 80% of that, and you'd quickly get
down to really short renewal times.

You also say above "mobile node decision."   This implies that you
think the mobile node is going to decide which addresses in an
identity association to renew, and which not to.  I don't see how that
can work.   Can you clarify what you intend here?

Finally, in your scenario the client is sending three seperate
renewals per identity association rather than one.   This will consume
more bandwidth in most cases, not less.   There should be a good
reason for splitting things out this way.   I'm not seeing the reason
why this is the right thing to do.

> Note I think the IA needs its own message type too to negotiate a new
> IA with the Server as it changes the bindings at the server and I assume
> the security keys.

The identity association is something the client declares.  There is
no negotiation.  To the server, it is simply a client-supplied
identifier with some structure that lets you compare two different
identifiers to see if they're from the same client.

> But if the client wants to request more addresses for an interface or a
> link or even an NBMA PVC connection they can set up a new IA and then
> send REQUEST to the server and the implementation above still works and
> can be its own module and thread on the server for all cases.  This
> supports what Charlie wanted.

Right.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 02:50:18 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15558
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 02:50:18 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F6mMb04416;
	Fri, 15 Sep 2000 02:48:22 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F6m9b22317
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 02:48:09 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-211.ip.theriver.com [206.97.58.211]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id FAA14159 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 05:54:37 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8F6j0029130 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 23:45:00 -0700 (MST)
Message-Id: <200009150645.e8F6j0029130@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 Relay Changes 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Fri, 15 Sep 2000 02:33:24 -0400." <200009150633.CAA0000710546@anw.zk3.dec.com> 
Date: Thu, 14 Sep 2000 23:45:00 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> The market will decide security mechanisms not us.

*smile*  There are some things that not even the Omniscient Hand of
the Market can make happen.   :')

We talked about how to use IPsec for DHCP authentication, and came up
with some theories, but all of them involved extra packet exchanges,
and ultimately we decided we didn't want that.   If the market really,
*really* wants it, I guess it'll happen, but I'm not placing any bets
on it.   That's between the client and server, of course - as you say,
IPsec between the relay and the server is fairly easy, and eminently
plausible, particularly in the cable modem environment where you want
to stuff additional options into the Relay message.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 03:29:05 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15901
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 03:29:05 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F7QZb21485;
	Fri, 15 Sep 2000 03:26:35 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F7QUb11673
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 03:26:30 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 80F951753; Fri, 15 Sep 2000 03:26:15 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id 610F01542
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 03:26:15 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id DAA0000715539; Fri, 15 Sep 2000 03:26:13 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009150726.DAA0000715539@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Thu, 14 Sep 2000 23:39:08 PDT."
             <200009150639.e8F6d8029024@grosse.bisbee.fugue.com> 
Date: Fri, 15 Sep 2000 03:26:12 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>> We don't want the identity assoication expiring before address
>> lifetimes that will cause big problems.

>It's not an expiry time.  It's a renewal time.  This allows us to
>renew all addresses in an identity association at the same time,
>rather than having each address's renewal come at a different time.
>The addresses do not expire until their lifetimes expire.

Ah then I don't agree with where you headed.  

>> All but one valid lifetime for one address are 10 hours.  But this one
>> address is 1 hour.   I don't think the client should have to send all 4
>> addreses across the wire to get one either more time or not more time.

>Yes, this could result in more bits passing across the wire in cases
>where the disparity between renewal times is very large.  But it would
>result in the same number of packets, so this would matter only in a
>context where indivual bits in a packet really count.  And I think
>this is actually a very unlikely scenario - can you come up with a
>reason why the lifetimes would be so different?

I was not concerned about the bits but the clients performance to update
one address.  

One address is global, one is site-local, and one is organizational.
Each have different thresholds.  Each have different times.
I would think the global would have less, and site the most time.

Also in IPv6 we do not make any assumptions about the times thus far and
treat them and their lifetimes as individual datums not as a group.
For that reason they can renew or release at any time.

Why do you think they would all be the same time?

>Anyway, in this case, 3Xk is greater than 2X, so address B will expire
>before the client renews, which probably isn't what you want - you
>want to renew address B *before* it expires.  So the renewal time has
>to be 2Xk, not 3Xk.

>> >Installs timeout at 2Xk to send a new DHCP Request.
>> >Installs timeout at X to delete address A
>> >Installs timeout at 2X to delete address B
>> >Installs timeout at 3X to delete address C
>> 
>> I don't think 3X should be running during renewal state.
>> 
>> I also think X should not have to wait for Request at renewal state.
>> But that implies we need more discussion for IA if it changes.

>All of the above timeouts are installed at the same time.

I know that and have implemented stateless this way too.

>> I don't agree with this.  What if the server is providing A as the nodes
>> global address to reach the Intratnet to the Internet and the others are
>> site local addresses.  The server wants the client to check back in for
>> global addresses not loose them after getting them once.  

>The scenario here is that address A is deprecated, and will not be
>renewed.   If address A is not deprecated, then it will be counted by
>the server in determining the renewal time, and so the renewal time
>will be Xk, not 2Xk.

Oh so in the reply (and I asked that) you were telling the client the
address was deprecated, but they have X time left?

How will the client know its deprecated?  

>> Address A
>>    at 80% Y
>>    if A will not be RELEASED by Client (mobile node decision)
>>                                        (for handoff as example using
>>                                         lazy cell evaluation)
>>       REQUEST address A again

>Address A is deprecated, meaning that the server will not extend it,
>so a request at this time would be met with a renewal for 20% Y, and
>then the new renewal time would be 80% of that, and you'd quickly get
>down to really short renewal times.

Ah Ha..we are not using terms the same way I don't think.  I am using
and DHCPv6 uses the term deprecated as defined in 2462.

Deprecated means that the preferred timer has went off but the valid
timer is still ticking.  So a telnet connection will continue in the
deprecated state until the valid lifetime goes off so before that
happens go get more time.

What I am proposing is something Thomas Narten wanted.

When the preferred timer is 80% till expiration go request new times or
another address from the server.

>You also say above "mobile node decision."   This implies that you
>think the mobile node is going to decide which addresses in an
>identity association to renew, and which not to.  I don't see how that
>can work.   Can you clarify what you intend here?

Sure.  The mobile node has an IPv6 address it can use in a particular
routing realm as its roaming.  It will know as it roams it is moving to
a new routing realm.  The prefix of the routing realm changes and it
knows it has to use a new address to communicate in the new routing
realm or in wireless terms cell with new Base Station.

>Finally, in your scenario the client is sending three seperate
>renewals per identity association rather than one.   This will consume
>more bandwidth in most cases, not less.   There should be a good
>reason for splitting things out this way.   I'm not seeing the reason
>why this is the right thing to do.

That was to depict that even though three separate messages were used
the same server code works.  The client would only send them as
addresses expires or are deprecated.  Depending on the lease for each
address these may get sent four hours apart as one example.

But also under your model the client cannot renew lets say their global
address until the renewal timer goes off which is based on the
site-local address as 2X as an example.  The client has to wait 2X
before it can ask for a new lease or address for global communications.

I believe the trade-off to permit the client to update individual
address lifetimes if the server permits it is worth it for the case wher
the client needs to update the lease even though their renewal has not
gone off.

>> Note I think the IA needs its own message type too to negotiate a new
>> IA with the Server as it changes the bindings at the server and I assume
>> the security keys.

>The identity association is something the client declares.  There is
>no negotiation.  To the server, it is simply a client-supplied
>identifier with some structure that lets you compare two different
>identifiers to see if they're from the same client.

How does the server do garbage collection then of IAs that are defunct
for some reason?  I don't want them sitting around in my database or
however I choose to implement the server config database?

In the current dhcpv6 model if the client releases the address the
binding also can be released by the implementation.  I think we need
some means to do that with the IA too.

The implementation reason is the same reason we balance binary trees
every now and then it reduces the search for the client when it comes to
the server.

regards,
/jim 



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 03:56:05 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA16161
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 03:56:05 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F7tib04564;
	Fri, 15 Sep 2000 03:55:44 -0400 (EDT)
Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F7tVb00796
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 03:55:32 -0400 (EDT)
Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345)
	id 88F4D1BDB; Fri, 15 Sep 2000 02:55:16 -0500 (CDT)
Received: from excmun-gh02.eur.compaq.com (excmun-gh02.dem.cpqcorp.net [16.41.92.161])
	by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 0E5231988
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 02:55:16 -0500 (CDT)
Received: by excmun-gh02.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21)
	id <SYN692FT>; Fri, 15 Sep 2000 09:55:13 +0200
Message-ID: <F3E1B076B5E8D211B8DD0000F803EC893868ED@vbeexc2.vbe.cpqcorp.net>
From: "Pouffary, Yanick" <Yanick.Pouffary@compaq.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal... 
Date: Fri, 15 Sep 2000 09:55:02 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Jim I thought you were going to sleep :-)

Yanick


		-----Original Message-----
		From:	Bound, Jim 
		Sent:	Friday, September 15, 2000 09:26
		To:	DHCPv6 discussion list
		Subject:	Re: DHCPv6 address model proposal... 


		>> We don't want the identity assoication expiring before
address
		>> lifetimes that will cause big problems.

		>It's not an expiry time.  It's a renewal time.  This allows
us to
		>renew all addresses in an identity association at the same
time,
		>rather than having each address's renewal come at a
different time.
		>The addresses do not expire until their lifetimes expire.

		Ah then I don't agree with where you headed.  

		>> All but one valid lifetime for one address are 10 hours.
But this one
		>> address is 1 hour.   I don't think the client should have
to send all 4
		>> addreses across the wire to get one either more time or
not more time.

		>Yes, this could result in more bits passing across the wire
in cases
		>where the disparity between renewal times is very large.
But it would
		>result in the same number of packets, so this would matter
only in a
		>context where indivual bits in a packet really count.  And
I think
		>this is actually a very unlikely scenario - can you come up
with a
		>reason why the lifetimes would be so different?

		I was not concerned about the bits but the clients
performance to update
		one address.  

		One address is global, one is site-local, and one is
organizational.
		Each have different thresholds.  Each have different times.
		I would think the global would have less, and site the most
time.

		Also in IPv6 we do not make any assumptions about the times
thus far and
		treat them and their lifetimes as individual datums not as a
group.
		For that reason they can renew or release at any time.

		Why do you think they would all be the same time?

		>Anyway, in this case, 3Xk is greater than 2X, so address B
will expire
		>before the client renews, which probably isn't what you
want - you
		>want to renew address B *before* it expires.  So the
renewal time has
		>to be 2Xk, not 3Xk.

		>> >Installs timeout at 2Xk to send a new DHCP Request.
		>> >Installs timeout at X to delete address A
		>> >Installs timeout at 2X to delete address B
		>> >Installs timeout at 3X to delete address C
		>> 
		>> I don't think 3X should be running during renewal state.
		>> 
		>> I also think X should not have to wait for Request at
renewal state.
		>> But that implies we need more discussion for IA if it
changes.

		>All of the above timeouts are installed at the same time.

		I know that and have implemented stateless this way too.

		>> I don't agree with this.  What if the server is providing
A as the nodes
		>> global address to reach the Intratnet to the Internet and
the others are
		>> site local addresses.  The server wants the client to
check back in for
		>> global addresses not loose them after getting them once.


		>The scenario here is that address A is deprecated, and will
not be
		>renewed.   If address A is not deprecated, then it will be
counted by
		>the server in determining the renewal time, and so the
renewal time
		>will be Xk, not 2Xk.

		Oh so in the reply (and I asked that) you were telling the
client the
		address was deprecated, but they have X time left?

		How will the client know its deprecated?  

		>> Address A
		>>    at 80% Y
		>>    if A will not be RELEASED by Client (mobile node
decision)
		>>                                        (for handoff as
example using
		>>                                         lazy cell
evaluation)
		>>       REQUEST address A again

		>Address A is deprecated, meaning that the server will not
extend it,
		>so a request at this time would be met with a renewal for
20% Y, and
		>then the new renewal time would be 80% of that, and you'd
quickly get
		>down to really short renewal times.

		Ah Ha..we are not using terms the same way I don't think.  I
am using
		and DHCPv6 uses the term deprecated as defined in 2462.

		Deprecated means that the preferred timer has went off but
the valid
		timer is still ticking.  So a telnet connection will
continue in the
		deprecated state until the valid lifetime goes off so before
that
		happens go get more time.

		What I am proposing is something Thomas Narten wanted.

		When the preferred timer is 80% till expiration go request
new times or
		another address from the server.

		>You also say above "mobile node decision."   This implies
that you
		>think the mobile node is going to decide which addresses in
an
		>identity association to renew, and which not to.  I don't
see how that
		>can work.   Can you clarify what you intend here?

		Sure.  The mobile node has an IPv6 address it can use in a
particular
		routing realm as its roaming.  It will know as it roams it
is moving to
		a new routing realm.  The prefix of the routing realm
changes and it
		knows it has to use a new address to communicate in the new
routing
		realm or in wireless terms cell with new Base Station.

		>Finally, in your scenario the client is sending three
seperate
		>renewals per identity association rather than one.   This
will consume
		>more bandwidth in most cases, not less.   There should be a
good
		>reason for splitting things out this way.   I'm not seeing
the reason
		>why this is the right thing to do.

		That was to depict that even though three separate messages
were used
		the same server code works.  The client would only send them
as
		addresses expires or are deprecated.  Depending on the lease
for each
		address these may get sent four hours apart as one example.

		But also under your model the client cannot renew lets say
their global
		address until the renewal timer goes off which is based on
the
		site-local address as 2X as an example.  The client has to
wait 2X
		before it can ask for a new lease or address for global
communications.

		I believe the trade-off to permit the client to update
individual
		address lifetimes if the server permits it is worth it for
the case wher
		the client needs to update the lease even though their
renewal has not
		gone off.

		>> Note I think the IA needs its own message type too to
negotiate a new
		>> IA with the Server as it changes the bindings at the
server and I assume
		>> the security keys.

		>The identity association is something the client declares.
There is
		>no negotiation.  To the server, it is simply a
client-supplied
		>identifier with some structure that lets you compare two
different
		>identifiers to see if they're from the same client.

		How does the server do garbage collection then of IAs that
are defunct
		for some reason?  I don't want them sitting around in my
database or
		however I choose to implement the server config database?

		In the current dhcpv6 model if the client releases the
address the
		binding also can be released by the implementation.  I think
we need
		some means to do that with the IA too.

		The implementation reason is the same reason we balance
binary trees
		every now and then it reduces the search for the client when
it comes to
		the server.

		regards,
		/jim 



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 04:10:02 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16261
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 04:10:01 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F87ab27703;
	Fri, 15 Sep 2000 04:07:36 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F87Mb22016
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 04:07:22 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-211.ip.theriver.com [206.97.58.211]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id HAA14301 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 07:13:48 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8F840000248 for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 01:04:01 -0700 (MST)
Message-Id: <200009150804.e8F840000248@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Fri, 15 Sep 2000 03:26:12 -0400." <200009150726.DAA0000715539@anw.zk3.dec.com> 
Date: Fri, 15 Sep 2000 01:03:59 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> One address is global, one is site-local, and one is organizational.
> Each have different thresholds.  Each have different times.
> I would think the global would have less, and site the most time.

Why would one identity association have all three of these?   Wouldn't
it either be asking for a global address or not?   How does the server
decide when the client can have a global address and when it can't?
If the client has a global address, why does it need a non-global one?

I think that if the client sometimes has a global address and
sometimes not, it's probably got two identity associations going - one
for the program that needs to have a global address, and one for the
programs that don't.

I may just be dense here, but the scenario you're describing where a
client has all three kinds of addresses at once sounds extremely
exotic to me.   In my own personal use, I am going to always request a
global address for my network interface, and if I get one, I'm not
going to have any interest in any other addresses.   Are you
envisioning a scenario where you have a global address starvation
problem or something?

Or is this a mobile IP scenario, where you have one global address
that you want to keep around, and then you have a site-local address
that changes a lot?  In this case, I think you have two identity
associations - the addresses are being used for completely different
purposes, so it doesn't make sense to treat them as part of the same
network identity.

> Also in IPv6 we do not make any assumptions about the times thus far and
> treat them and their lifetimes as individual datums not as a group.
> For that reason they can renew or release at any time.
> 
> Why do you think they would all be the same time?

I don't see any reason why one address would have a different lifetime
from another.  I can imagine that they might have different lifetimes
by happenstance, but why would they have *different* times?  It's more
work for the network administrator to specify that addresses in this
class have lifetimes of ten hours, but addresses in this class have
lifetimes of twenty.  The only case where I think addresses are likely
to have significantly different lifetimes is when you are renumbering,
and one of the addresses the server has that the client is using has a
time when the *server* isn't supposed to give it out anymore.  So yes,
lifetimes are individual data, but I think it makes sense to treat the
lifetimes of addresses in an identity association collectively anyway.

> Oh so in the reply (and I asked that) you were telling the client the
> address was deprecated, but they have X time left?
> 
> How will the client know its deprecated?  

Probably deprecated addresses have a different extension number but
share the IP Address Extension format.

> Deprecated means that the preferred timer has went off but the valid
> timer is still ticking.  So a telnet connection will continue in the
> deprecated state until the valid lifetime goes off so before that
> happens go get more time.

This is complicated because there are really two sets of lifetimes on
addresses.   There's the lifetime the server knows, and the lifetime
the client knows.   The server may have address pools for which it
knows of no time when it can no longer give out the address, in which
case the lifetime it gives to the client is going to be basically a
lease time.   Setting the preferred time to 80% of the valid time
sounds reasonable, but the choice of valid time is going to be
basically what the server administrator configures in.

When I talk about deprecated addresses, I'm talking about renumbering.
The address A in the scenario I was describing has been renumbered,
and so the server isn't going to renew it.  The server has a drop dead
time on the pool from which that address came, and no matter how often
the client tries to renew that address, it's always going to be told
that address becomes invalid at the same actual time.

The way you (IPv6) are using deprecated is unfortunate, because it
leaves me without a word to describe a lease that will never be
extended, which seems like it's also an important IPv6 concept.   But
be that as it may, using the IPv6 meaning of deprecated, we want the
renewal time on the identity association to be the minimum of all the
preferred lifetimes of all the addresses in that identity association.

> Sure.  The mobile node has an IPv6 address it can use in a particular
> routing realm as its roaming.  It will know as it roams it is moving to
> a new routing realm.  The prefix of the routing realm changes and it
> knows it has to use a new address to communicate in the new routing
> realm or in wireless terms cell with new Base Station.
> 

So the client is going to tell the server "I only want addresses with
this prefix?"

> But also under your model the client cannot renew lets say their global
> address until the renewal timer goes off which is based on the
> site-local address as 2X as an example.  The client has to wait 2X
> before it can ask for a new lease or address for global communications.

No, that's not right.   The renewal time is the minimum preferred
lifetime for all the addresses in the identity association.  So the
client *has* to renew the global address just as it becomes
v6deprecated.

> I believe the trade-off to permit the client to update individual
> address lifetimes if the server permits it is worth it for the case wher
> the client needs to update the lease even though their renewal has not
> gone off.

The client is also free to renew anytime it wants prior to the lease
expiry, just like in DHCPv4.   So this doesn't seem like a problem.

> How does the server do garbage collection then of IAs that are defunct
> for some reason?  I don't want them sitting around in my database or
> however I choose to implement the server config database?

As soon as there are no valid addresses associated with an IA, you
can gc the IA.

> The implementation reason is the same reason we balance binary trees
> every now and then it reduces the search for the client when it comes to
> the server.

This makes sense.   In a high turnover environment, you'd want to be
smart about harvesting stale IAs.   However, in an environment with
a more consistent set of clients, which is the typical DHCPv4
scenario, this isn't a real problem.   And in either case, I don't
think there's any need for a special negotiation.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 04:10:39 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16288
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 04:10:39 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8F8ANb25427;
	Fri, 15 Sep 2000 04:10:23 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8F8AIb19735
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 04:10:18 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-211.ip.theriver.com [206.97.58.211]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id HAA14309 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 07:16:46 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8F874000306 for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 01:07:04 -0700 (MST)
Message-Id: <200009150807.e8F874000306@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from "Pouffary, Yanick" <Yanick.Pouffary@compaq.com> 
   of "Fri, 15 Sep 2000 09:55:02 +0200." <F3E1B076B5E8D211B8DD0000F803EC893868ED@vbeexc2.vbe.cpqcorp.net> 
Date: Fri, 15 Sep 2000 01:07:04 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


It's only four in the morning, and Jim's espresso machine still has
beans in it, so the night is young.  :')   However, I should go to bed
and stop keeping Jim awake...

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 09:04:56 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19091
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 09:04:55 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8FD2Eb17186;
	Fri, 15 Sep 2000 09:02:14 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8FD27b11033
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 09:02:07 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <SS53T2QK>; Fri, 15 Sep 2000 09:01:52 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC163@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 Relay Changes
Date: Fri, 15 Sep 2000 09:01:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I agree with Ted's proposal that the entire DHCPv6 (UDP data portion) is
encapsulated in a "Relayed Data" option. The DHCPv6 relay can add other
options to the "new" DHCPv6 message, such as relay agent options, etc.

So, a relay receives a DHCPv6 message (UDP data portion only), creates a new
message that it sends to the server, that message contains:
	DHCPv6 header
	DHCPv6 relay added options
	DHCPv6 "Relayed Data" option which contains the original DHCPv6
message received from the client
	DHCPv6 relay added options

(We could require the relay added options to appear either before or after
the relayed data option or allow the relay to add some before and some
after.)

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Friday, September 15, 2000 2:45 AM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 Relay Changes



> The market will decide security mechanisms not us.

*smile*  There are some things that not even the Omniscient Hand of
the Market can make happen.   :')

We talked about how to use IPsec for DHCP authentication, and came up
with some theories, but all of them involved extra packet exchanges,
and ultimately we decided we didn't want that.   If the market really,
*really* wants it, I guess it'll happen, but I'm not placing any bets
on it.   That's between the client and server, of course - as you say,
IPsec between the relay and the server is fairly easy, and eminently
plausible, particularly in the cable modem environment where you want
to stuff additional options into the Relay message.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 09:10:02 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19134
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 09:10:02 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8FD9fb09315;
	Fri, 15 Sep 2000 09:09:41 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8FD9Wb21141
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 09:09:33 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <SS53T2QW>; Fri, 15 Sep 2000 09:09:17 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC164@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Design team teleconference, 8/31
Date: Fri, 15 Sep 2000 09:09:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Recall that we did want a quick way for a client to get an address in DHCPv6
- a single message in each direction.

So, perhaps we use the old "DISCOVER" message to perform this function
(adding a new message to DHCPv6). Or, perhaps the DHCPSOLICIT can include an
option that would say to the server give me some addreses.

I do like the new DHCPv6 method better than the DHCPv4 method since it
doesn't require the server to temporarily reserve an address for a short
time. While with V6 we have plenty of address space, it just seems a bad way
to go to me.

How many DHCPv4 clients really take a look at what the server is offering
and base a decision on whether to accept on that? I suspect most clients
take the first offer they receive.

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Friday, September 15, 2000 1:41 AM
To: DHCPv6 discussion list
Subject: Re: Design team teleconference, 8/31



The advantage of DHCPDISCOVER/DHCPOFFER is that the DHCPDISCOVER
message asks for an IP address, and DHCPOFFER can say "this is the
address I will give you if you pick me."  DHCPsolicit/DHCPadvertise
doesn't provide this functionality.  I think that this is useful
functionality, and I am loath to give it up.

I can see why you like your new way of doing things, but there is
definitely a good reason to continue with the old method, or at least
so it seems to me.  Is this a strong enough reason to go back?   I
can't say.   In my mind it is.   It sounds like Ralph agrees.   I'd be
interested in seeing if anybody else wants to weigh in on the issue.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 09:33:13 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19348
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 09:33:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8FDWfb26848;
	Fri, 15 Sep 2000 09:32:41 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8FDWOb28499
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 09:32:24 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-127.cisco.com [161.44.133.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA01788 for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 09:32:05 -0400 (EDT)
Message-Id: <4.3.1.2.20000915092521.00b92590@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 15 Sep 2000 09:29:27 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9,
  18 on Co nference Call Agenda)
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEC08E@lespaul.process.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 09:51 AM 9/1/00 -0400, you wrote:
>During the DHCPv6 conference call on Thursday, August 31st, I was assigned
>the "responsibility" of coming to a resolution on reconfiguration in DHCPv6
>(items 8, 9, and 18 on Ralph's compiled list):

We might need to answer these out of order - if the answer to 18 is 
"DHCPv4-style unicast only", then the answer to 8 will be at least limited 
to the Reconfigure-init message.

>8. Allow Reconfigure and Reconfigure-reply messages to be sent via a
>     relay to client's which do not have such reachable IP addresses, in
>     order to inform them of changes in non-releasable resources?  The
>     same thing could also go for Reconfigure-init to some extent.
>
>9. Might a client send a Solicit in response to a Reconfigure-init?
>     What if the topology changes such that this is necessary in order
>     find a DHCP server with can allocate addresses on the new subnet?
>
>18. Simplify reconfiguration; Use DHCPv4-style reconfiguration
>
>I believe the general consensus was a desire to use the DHCPv4-style
>reconfiguration (unicast from server to client).

I agree.

>  However, there is also a
>desire to accommondate multicasting as for major network reconfiguration
>events, unicasting may inefficient (if there are 1000's of clients to
>notify). But multicasting opens up significant security issues.

I don't think multicast adds efficiency.  It only reduces the number of 
messages by a constant factor (1/2 at best) and makes reliable 
communication with clients significantly more difficult.  Security is also 
a significant issue for multicast.

We can always add multicast later...

- Ralph



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 10:45:15 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20348
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 10:45:14 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8FEfrb21141;
	Fri, 15 Sep 2000 10:41:53 -0400 (EDT)
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8FEflb12681
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 10:41:47 -0400 (EDT)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA41386
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 10:41:31 -0400
Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA30392
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 10:41:31 -0400
Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id KAA26191 for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 10:39:37 -0400
Message-Id: <200009151439.KAA26191@rotala.raleigh.ibm.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Ted Lemon <mellon@nominum.com> 
   of "Fri, 15 Sep 2000 01:03:59 PDT." <200009150804.e8F840000248@grosse.bisbee.fugue.com> 
Date: Fri, 15 Sep 2000 10:39:37 -0400
From: Thomas Narten <narten@RALEIGH.IBM.COM>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hi Ted.

Your note seems to indicate a very different thinking between how you
see DHCP being used for addresses (and how addresses are used) and the
predominant view within the IPv6 community (or at least, my read of
the IPng view).  I think it would be good to fully understand the
differences and implications here.

> > One address is global, one is site-local, and one is organizational.
> > Each have different thresholds.  Each have different times.
> > I would think the global would have less, and site the most time.

> Why would one identity association have all three of these?   Wouldn't
> it either be asking for a global address or not?   How does the server
> decide when the client can have a global address and when it can't?
> If the client has a global address, why does it need a non-global
> one?

In general, addresses are just used. You don't really care which
address (or addresses) you have, so long as you have one(s) that work.

So, whenever someone suggests a view that a client asks for (say) a
global address, or perhaps a different type of address, this implies a
model in which the client (or application or whatever entity will use
the address(es)) needs to have a fair amount of knowledge about what
addresses are available, and how an address will be used. This model
is very different than the one assumed when stateless address
autoconfiguration is used. In that model, the system admin has says
(via configuration): the following addresses are the ones you will
need, assign them to your interfaces and use them.

Thus, the dhcpv6 counterpart to that model would be for a client (or
application or whatever) to say "I need some addresses", and the dhcp
server would return a *set* of addresses, corresponding to what is
appropriate *for the local network configuration* (as opposed to what
is appropriate for the specific usage enivisioned by the client).

> I think that if the client sometimes has a global address and
> sometimes not, it's probably got two identity associations going - one
> for the program that needs to have a global address, and one for the
> programs that don't.

Again, here you are implying a lot of client knowledge about the world
around it. How does the client know what addresses are available? How
does it know which ones would be appropriate to use? In general, I
would assume that the sys admin decides this, and when a client asks
for an address, it should be asking for an "address set", not a
specific address. The server then always returns the appropriate set
of addresses. This eliminates the need for clients to know what
addresses might be available and which ones of those it should ask
for.

> I may just be dense here, but the scenario you're describing where a
> client has all three kinds of addresses at once sounds extremely
> exotic to me.   In my own personal use, I am going to always request a
> global address for my network interface, and if I get one, I'm not
> going to have any interest in any other addresses.   Are you
> envisioning a scenario where you have a global address starvation
> problem or something?

The case where a client three kinds of addresses will likely be the
norm in IPv6. Or at least very common. Specific examples:

1) a site may have a global prefix (and hence global addresses for all
   hosts) plus a site-local prefix/address. The site-local address is
   nice because it will always work for intra-site communication, even
   of global  prefixes stop working, for example, as a result of
   switching ISPs and renumbering.

2) When a site is in the process  of renumbering, there will likely be
   a transition period where two global prefixes will be in use. The
   "old" one that is being phased out, and the new one being phased
   in. The transition period may well last weeks, in order to make
   sure that all traffic has switched to the  new addresses *before*
   disabling the old addresses.

Note that in scenario 2) above, a client most likely won't know a
renumbering event is going on, so it won't really know what kind of
address to ask for (does it ask for the old one? the new one?
both?). These are the types of questions that I believe complicate the
issues surrounding address allocation. Doing everything in terms of
"address sets", where the client always asks for a set, and the server
always returns a set, simplifies a lot of the potential corner cases
we would need to think about.

> Or is this a mobile IP scenario, where you have one global address
> that you want to keep around, and then you have a site-local address
> that changes a lot?  In this case, I think you have two identity
> associations - the addresses are being used for completely different
> purposes, so it doesn't make sense to treat them as part of the same
> network identity.

In the mobile IP scenario, you will likely have *two* global
addresses. One for your home address, and a temporary care of
address. Both will need to be global in order for arbitrary sites to
send packets to them. Note, however, that in this case the client will
be interacting with two different DHCP servers in two different
contexts. The care-of address comes from the local site that is being
visited, the home address comes from the home site. So it's not clear
you need to identity associations separately here (though you might
want to), since two servers are involved and that is enough to
distinguish which addresses one is talking about (i.e., care-of
vs. home).

> > Also in IPv6 we do not make any assumptions about the times thus far and
> > treat them and their lifetimes as individual datums not as a group.
> > For that reason they can renew or release at any time.
> > 
> > Why do you think they would all be the same time?

> I don't see any reason why one address would have a different lifetime
> from another. I can imagine that they might have different lifetimes
> by happenstance, but why would they have *different* times?  It's more
> work for the network administrator to specify that addresses in this
> class have lifetimes of ten hours, but addresses in this class have
> lifetimes of twenty.  The only case where I think addresses are likely
> to have significantly different lifetimes is when you are renumbering,
> and one of the addresses the server has that the client is using has a
> time when the *server* isn't supposed to give it out anymore.  So yes,
> lifetimes are individual data, but I think it makes sense to treat the
> lifetimes of addresses in an identity association collectively
> anyway.

I'm not sure whether you are agreeing or disagreeing above. On the one
hand you say, lifetimes should be the same, then you point out that
they won't be during renumbering events. If it can happen, then we
have to assume it will as a design point.

Another example of where lifetimes may be significantly different is
site-local vs. global. Since one probably never expects to renumber
site-local prefixes, they may have lifetimes of weeks/months, whereas
a global address may have a lifetime of only a week or so. In any
case, I don't think we should be making assumptions that lifetimes
will be the same. That is probably too restrictive.

> > Oh so in the reply (and I asked that) you were telling the client the
> > address was deprecated, but they have X time left?
> > 
> > How will the client know its deprecated?  

> Probably deprecated addresses have a different extension number but
> share the IP Address Extension format.

Any addresses returned by a the DHCP server will need to have
explicit Valid Lifetime and Preferred Lifetimes. Just as DHCPv4
addresses have a lifetime associated with the address, IPv6 addresses
have two lifetimes associated with them. This is a property of IPv6
addresses, not something that results from DHCP.

> > Deprecated means that the preferred timer has went off but the valid
> > timer is still ticking.  So a telnet connection will continue in the
> > deprecated state until the valid lifetime goes off so before that
> > happens go get more time.

> This is complicated because there are really two sets of lifetimes on
> addresses.

Yes, but that is a feature of IPv6 addresses. We just have to accept
this.

> There's the lifetime the server knows, and the lifetime
> the client knows.

How is this different than DHCPv4? Conceptually, there is the lease
time the server told the client, and there is the lifetime the server
has. The server could be extending the  lease in real time (e.g, it
always thinks of it  being (say) 2 days, but from the client's
perspective, it varies between 2 days and whatever the time is when it
renews the lease. (Or am I misunderstanding your point?)

> The server may have address pools for which it
> knows of no time when it can no longer give out the address, in which
> case the lifetime it gives to the client is going to be basically a
> lease time.   Setting the preferred time to 80% of the valid time
> sounds reasonable, but the choice of valid time is going to be
> basically what the server administrator configures in.

Yes. The sys admin will need to specify the Preferred Lifetime of all
addresses. (It can do this by saying that all addresses on subnet X
have the same value though.)

> When I talk about deprecated addresses, I'm talking about renumbering.
> The address A in the scenario I was describing has been renumbered,
> and so the server isn't going to renew it.

A deprecated address is still a valid address and the DHCP server
should hand them out. If it doesn't a client that attempts to renew an
address with 5 day valid lifetime on it may find the server is telling
it it can't have the address anymore. But this may break the smooth
renumbering goals of IPv6.

But I think you bring up a good point. In DHCPv6, the client should
renew an address *before* it becomes deprecated. But if the server
isn't going to extend the preferred lifetime (while allowing the
client to continue using an addresss -- so it does need to return the
address), the client needs to learn that in a definitive
way. Otherwise, it may continue to ask to extend the lease, not fully
understanding that the server is saying "no".

So, using the term "extend the lease" is not very good
terminology. Because it doesn't fully capture the two lifetimes of an
address.

> The server has a drop dead
> time on the pool from which that address came, and no matter how often
> the client tries to renew that address, it's always going to be told
> that address becomes invalid at the same actual time.

> The way you (IPv6) are using deprecated is unfortunate, because it
> leaves me without a word to describe a lease that will never be
> extended, which seems like it's also an important IPv6 concept.   But
> be that as it may, using the IPv6 meaning of deprecated, we want the
> renewal time on the identity association to be the minimum of all the
> preferred lifetimes of all the addresses in that identity
> association.

Agree we have a terminology problem, so maybe we should invent a new
term to describe things.

I also think you are basically right on the renewal point, but I think
there may be subtleties here that we haven't thought through
completely (as I allude to above with regards to knowing when the
preferred time is not going to be extended).

> > Sure.  The mobile node has an IPv6 address it can use in a particular
> > routing realm as its roaming.  It will know as it roams it is moving to
> > a new routing realm.  The prefix of the routing realm changes and it
> > knows it has to use a new address to communicate in the new routing
> > realm or in wireless terms cell with new Base Station.
> > 

> So the client is going to tell the server "I only want addresses with
> this prefix?"

I hope not. If a client moves to a new link/subnet, it should just
request that the DHCP server "give me the set of addresses that I'm
supposed to have on the new link I just joined".

> > But also under your model the client cannot renew lets say their global
> > address until the renewal timer goes off which is based on the
> > site-local address as 2X as an example.  The client has to wait 2X
> > before it can ask for a new lease or address for global communications.

> No, that's not right.   The renewal time is the minimum preferred
> lifetime for all the addresses in the identity association.  So the
> client *has* to renew the global address just as it becomes
> v6deprecated.

I wonder if we should have an explicit renewal time defined by DHCP
that tells the client when to renew, rather than have it derive the
info off the address lifetimes.

Thomas



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 13:40:20 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22978
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 13:40:19 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8FHbEb27231;
	Fri, 15 Sep 2000 13:37:15 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8FHb5b23110
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 13:37:05 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a17.pm3-24.theriver.com [206.102.192.33]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id QAA15046 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 16:43:31 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8FHXfH00679 for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 10:33:45 -0700 (MST)
Message-Id: <200009151733.e8FHXfH00679@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Design team teleconference, 8/31 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Fri, 15 Sep 2000 09:09:16 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC164@lespaul.process.com> 
Date: Fri, 15 Sep 2000 10:33:41 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> How many DHCPv4 clients really take a look at what the server is offering
> and base a decision on whether to accept on that? I suspect most clients
> take the first offer they receive.

The Windows 95 client went to the opposite extreme - it looked at the
address and wouldn't accept it unless it was the one it used to have
or was on a different subnet.   I don't know what newer Windows
clients do.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 14:29:00 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23633
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 14:29:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8FIQHb21371;
	Fri, 15 Sep 2000 14:26:17 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8FIQEb29027
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 14:26:14 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a17.pm3-24.theriver.com [206.102.192.33]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id RAA15201 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 17:32:40 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8FIMoH01306 for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 11:22:50 -0700 (MST)
Message-Id: <200009151822.e8FIMoH01306@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Thomas Narten <narten@RALEIGH.IBM.COM> 
   of "Fri, 15 Sep 2000 10:39:37 -0400." <200009151439.KAA26191@rotala.raleigh.ibm.com> 
Date: Fri, 15 Sep 2000 11:22:50 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Your note seems to indicate a very different thinking between how you
> see DHCP being used for addresses (and how addresses are used) and the
> predominant view within the IPv6 community (or at least, my read of
> the IPng view).  I think it would be good to fully understand the
> differences and implications here.

On the contrary - I am trying to understand why I am being told that
the client would have all these different kinds of addresses.  Why
would the server administrator say "give the client a global address,
*and* a site-local address?"  Why wouldn't it provide one or the
other?  I understand how during renumbering you might give a client
two addresses, but under what other circumstances does this make
sense?

I completely agree with you that it doesn't make sense for the client
to be making these kinds of decisions.

> 1) a site may have a global prefix (and hence global addresses for all
>    hosts) plus a site-local prefix/address. The site-local address is
>    nice because it will always work for intra-site communication, even
>    of global  prefixes stop working, for example, as a result of
>    switching ISPs and renumbering.
> 
> 2) When a site is in the process  of renumbering, there will likely be
>    a transition period where two global prefixes will be in use. The
>    "old" one that is being phased out, and the new one being phased
>    in. The transition period may well last weeks, in order to make
>    sure that all traffic has switched to the  new addresses *before*
>    disabling the old addresses.

Okay, this explains why the client would get a site-local and a global
address.   I already understood the bit about the two global addresses
during renumbering - that's why I proposed the scheme I did.

> Doing everything in terms of "address sets", where the client always
> asks for a set, and the server always returns a set, simplifies a
> lot of the potential corner cases we would need to think about.

Right.   That's what I've been trying to argue in favor of - each
identity association has an address set.   The entire set of addresses
in an identity association is renewed at once.   The server tells the
client what's in the address set, and when to renew, and also what the
lifetimes of the individual addresses are.

> In the mobile IP scenario, you will likely have *two* global
> addresses. One for your home address, and a temporary care of
> address. Both will need to be global in order for arbitrary sites to
> send packets to them. Note, however, that in this case the client will
> be interacting with two different DHCP servers in two different
> contexts. The care-of address comes from the local site that is being
> visited, the home address comes from the home site. So it's not clear
> you need to identity associations separately here (though you might
> want to), since two servers are involved and that is enough to
> distinguish which addresses one is talking about (i.e., care-of
> vs. home).

Right.   So you have two identity associations.

> I'm not sure whether you are agreeing or disagreeing above. On the one
> hand you say, lifetimes should be the same, then you point out that
> they won't be during renumbering events. If it can happen, then we
> have to assume it will as a design point.

Yes, and the design I've proposed here addresses this problem very
neatly.  If you put renewal times (note that I am _not_ talking about
lifetimes here!) on addresses, not identity associations, then you
have these problems:

  (1) even if the addresses all have very similar lifetimes, you
      probably send a seperate renewal packet for each address.
  (2) If an address is deprecated, and will not be renewed once its
      lifetime expires, then as its life comes to an end, the client's
      renewal rate increases exponentially 
  (3) It's hard for the server to cause you to change your address
      set, because you're never having a conversation about an address
      set, but only about an address.   So you have to have a lot of
      additional goo in the protocol to make it possible for the
      server to give you a new address set.

If you renew the identity association, you have these advantages:

  (1) You always renew all addresses in the same request, which
      happens at the time you would have had to do the first renewal
      anyway.   This reduces complexity in the client, and reduces
      traffic on the network, although there is a marginal increase in
      packet size.
  (2) If a global address has been renumbered and is not renewable, the
      server doesn't count it in the renewal time, so you don't get an
      exponential curve in the client renewal rate as the address
      expires - the client simply deletes the address from its
      interface when it's no longer valid, completely seperate from
      the renewal process.
  (3) If for some reason you need a different set of addresses, the
      server will tell you all of them when you renew - no muss, no
      fuss.

> Any addresses returned by a the DHCP server will need to have
> explicit Valid Lifetime and Preferred Lifetimes. Just as DHCPv4
> addresses have a lifetime associated with the address, IPv6 addresses
> have two lifetimes associated with them. This is a property of IPv6
> addresses, not something that results from DHCP.

I understand this.  Maybe I should use the term "non-renewable" here -
saying the address is deprecated is causing confusion.  There's no
actual need for the client to know that the address is non-renewable -
I only suggest that it be told because it's less likely that an
implementor will make a mistake if non-renewable addresses are
explicitly treated differently.

> > This is complicated because there are really two sets of lifetimes on
> > addresses.
> 
> Yes, but that is a feature of IPv6 addresses. We just have to accept
> this.

I'm not saying we don't have to accept it.  I'm describing how to
handle it.  I get the feeling in your message that you're getting the
impression that I don't know what I'm talking about.  Please don't
read my messages this way - I actually do have a pretty good sense of
what I'm talking about.  I'm just having trouble with the terminology.
I don't remember all the IPv6 terms because I don't read the drafts
every day, and IPv6 uses a fair amount of specialized terminology,
some of which has overlapping uses.  This statement was made to
clarify a place where two meanings for the same set of words overlap,
not to say that we should only have one meaning for that set of
words.

> A deprecated address is still a valid address and the DHCP server
> should hand them out. If it doesn't a client that attempts to renew an
> address with 5 day valid lifetime on it may find the server is telling
> it it can't have the address anymore. But this may break the smooth
> renumbering goals of IPv6.

There are addresses that, to the client, are (in IPv6 terminology)
deprecated, but that the server will renew, at which time from the
client's perspective, the address will no longer be deprecated.  Then
there are addresses that are deprecated from the server's perspective
- that is, after a certain time (the valid time), the server should no
longer renew them, and after a different, earlier time (the preferred
time), the server shouldn't do new allocations with them.  I'm now
calling these addresses "non-renewable."

If the client requests a renewal prior to the end of the server's idea
of the valid time for one of these addresses, the server should renew
it, but not extend it.  The client's renewal time can't be based on
the valid time or preferred time that the client gives to the server,
because the server will not extend the valid or preferred time on this
address.  So if the client tries to renew based on the relative times
it gets for this address, you get into the exponential upward renewal
rate.

The only usual case where the server should have to tell the client
again about this address after it's become non-renewable is if the
client is renewing some *other* address, or if the client reboots.
And yes, then the server should give the address to the client again,
with the same absolute valid lifetime and absolute preferred lifetime
as before.

> I hope not. If a client moves to a new link/subnet, it should just
> request that the DHCP server "give me the set of addresses that I'm
> supposed to have on the new link I just joined".

This sounds like the client is making a different request depending on
it's perception of the status of the link.  Is there any particular
reason why the client can't just say "please renew this IA" and have
the server say "okay, because you're on a new link, here are your new
addresses?"  I.e., the client asks the same question, rather than
having to be clever and decide which question to ask?   The client
might be stimulated to ask for an early renewal because it noticed
that the router advertisements it was seeing had changed, but I don't
think it needs to explicitly tell the server "hey, I'm on a new
subnet."

The reason I say this is that the server has to decide what address is
appropriate for the client *anyway* - the client may have lost its
cookies.   So if we have to implement this on the server side, why
bother putting it in the client?   One of our stated goals was to keep
the client simple, after all.

> I wonder if we should have an explicit renewal time defined by DHCP
> that tells the client when to renew, rather than have it derive the
> info off the address lifetimes.

I presume you mean explicitly stated by the server, not explicitly
stated in the protocol.  If you mean the former thing, that's exactly
what I've been proposing!

I think we're actually not very far apart here - it just seems like
we're farther apart because we're using terminology in different ways.
I'm sorry for not grokking the IPv6 terminology better - I've got too
many things on my plate right now to really be up on this, but by
clarifying it as you have done, you've at least helped me with the
particular mistakes I made in this most recent set of message.  :'}

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 15:23:56 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24174
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 15:23:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8FJKOb06655;
	Fri, 15 Sep 2000 15:20:24 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8FJKCb31242
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 15:20:12 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 16DA51C87; Fri, 15 Sep 2000 15:19:57 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id 016AC1E35
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 15:19:56 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id PAA0000796189; Fri, 15 Sep 2000 15:19:39 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009151919.PAA0000796189@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Fri, 15 Sep 2000 01:07:04 PDT."
             <200009150807.e8F874000306@grosse.bisbee.fugue.com> 
Date: Fri, 15 Sep 2000 15:19:39 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>It's only four in the morning, and Jim's espresso machine still has
>beans in it, so the night is young.  :')   However, I should go to bed
>and stop keeping Jim awake...

Well I did get about 5 hours in.  And yep had that expresso machine out
again....But seriously its very good to keep this debate going now if
the editors are to get this next rev out per the schedule but I think we
are slipping.

/jim



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 16:13:56 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24564
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 16:13:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8FKBDb16837;
	Fri, 15 Sep 2000 16:11:13 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8FKArb24977
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 16:10:56 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 4515315C1; Fri, 15 Sep 2000 16:10:36 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id 110DF144E
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 16:10:36 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id QAA0000806898; Fri, 15 Sep 2000 16:10:35 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009152010.QAA0000806898@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Fri, 15 Sep 2000 01:03:59 PDT."
             <200009150804.e8F840000248@grosse.bisbee.fugue.com> 
Date: Fri, 15 Sep 2000 16:10:34 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>> One address is global, one is site-local, and one is organizational.
>> Each have different thresholds.  Each have different times.
>> I would think the global would have less, and site the most time.

>Why would one identity association have all three of these?   Wouldn't
>it either be asking for a global address or not?   How does the server
>decide when the client can have a global address and when it can't?
>If the client has a global address, why does it need a non-global one?

These are good questions I hope folks will read my response it is an
important data point we discuss this and what is driving my assumptions.

But to answer the above it is server admin policy which we don't define
in DHCPv6 or DHCPv4 and we should not for DHCPng thinking of tomorrow.

>I think that if the client sometimes has a global address and
>sometimes not, it's probably got two identity associations going - one
>for the program that needs to have a global address, and one for the
>programs that don't.

That makes things more complex IMO than what we have now in DHCPv6.

If we went down this path then we would want a way for the client to let
the server know what it wants and I don't think we should do that and
then we are heading back to the existing spec which I don't think is
wrong but appears to be complex to get implementors excited.  But the
real issue is why I want this and why it is innate to IPv6 Stateless
Addrconf for which I think the DHCPv6 model should support.

>I may just be dense here, but the scenario you're describing where a
>client has all three kinds of addresses at once sounds extremely
>exotic to me.   In my own personal use, I am going to always request a
>global address for my network interface, and if I get one, I'm not
>going to have any interest in any other addresses.   Are you
>envisioning a scenario where you have a global address starvation
>problem or something?

Its not exotic at all.  Here is why in IPv6 we have as you know multiple
address scopes and right now the IPng WG and IPv6 implementors are
working on what is called the Source Address Selection algorithm.  The
bottom line is that if a node does getaddrfino() to find host foo and
gets back a site-local address the source address selection rule set in
an IPv6 implementation will attempt to find the best match address to
use for that destination scope.  So a site-local address will be used
for the source address not the global address.   But if the same node
wants to ftp to a global ftp Internet site then it will want to use a
global source address.  When you want to access your organization server
for something DNS may return an orgganizational scope address and then
the best match for the source address is organization.  The work also
addresses disimilar scopes and if apps hard code the address of course.

But the point is that IPv6 endorses and assumes IPv6 nodes for one
interface may want to have many many addresses of different scopes as I
depict above and the IP6 architecture permits the behavior.  I believe
DHCPv6 must all support that behavior and in fact DHCPv6 would be in
error if it did not.

This is not my (Jim's) architecture but what the authors do have the
intention of supporting the IPv6 architecture and be in synch to some
degree with rfc2461 and rfc2462 (Neighbor Discovery and Stateless
Addrconf).

>Or is this a mobile IP scenario, where you have one global address
>that you want to keep around, and then you have a site-local address
>that changes a lot?  In this case, I think you have two identity
>associations - the addresses are being used for completely different
>purposes, so it doesn't make sense to treat them as part of the same
>network identity.

Mobility is another example.  I can see your model above but I can see
the need for mine too.   I think it easier and less name space pollution
of the IA's if we permit the behavior I am supporting (not my idea OK
but I think its a good idea).

>> Also in IPv6 we do not make any assumptions about the times thus far and
>> treat them and their lifetimes as individual datums not as a group.
>> For that reason they can renew or release at any time.
>> 
> Why do you think they would all be the same time?

>I don't see any reason why one address would have a different lifetime
>from another.  I can imagine that they might have different lifetimes
>by happenstance, but why would they have *different* times?  It's more
>work for the network administrator to specify that addresses in this
>class have lifetimes of ten hours, but addresses in this class have
>lifetimes of twenty.  The only case where I think addresses are likely
>to have significantly different lifetimes is when you are renumbering,
>and one of the addresses the server has that the client is using has a
>time when the *server* isn't supposed to give it out anymore.  So yes,
>lifetimes are individual data, but I think it makes sense to treat the
>lifetimes of addresses in an identity association collectively anyway.

I gave you example above.  The global may have less time significantly
than the site-local which I presume would have the most time.

>> Oh so in the reply (and I asked that) you were telling the client the
>> address was deprecated, but they have X time left?
>> 
>> How will the client know its deprecated?  

>Probably deprecated addresses have a different extension number but
>share the IP Address Extension format.

Hmm I need to think about that if this is what we do at the end of the
day.

>When I talk about deprecated addresses, I'm talking about renumbering.
>The address A in the scenario I was describing has been renumbered,
>and so the server isn't going to renew it.  The server has a drop dead
>time on the pool from which that address came, and no matter how often
>the client tries to renew that address, it's always going to be told
>that address becomes invalid at the same actual time.

OK in that scenario which I did not know obviously from your mail
In the scenario I am supporting the Server would respond with valid
lifetime of 2 minutes which will end the address and cause deletion of
that address for the IA.

Note in IPv6 Addrconf Stateless you cannot send a valid lifetime of zero.

>The way you (IPv6) are using deprecated is unfortunate, because it
>leaves me without a word to describe a lease that will never be

Its not the way "I" am using deprecated its the way IPv6 uses the word
deprecated.  I think for communications and my intent and debate I want
all to know I am advocating use model in IPv6 Stateless Addrconf and
Neighbor Discovery when possible and if we don't there must be a
compelling reason.  Thank You.  So if you don't like this you don't like
what IPv6 has done.

>extended, which seems like it's also an important IPv6 concept.   But
>be that as it may, using the IPv6 meaning of deprecated, we want the
>renewal time on the identity association to be the minimum of all the
>preferred lifetimes of all the addresses in that identity association.

That is fine if we use that model.  I am not clear now after this
discussion if that is a good model now.

>> Sure.  The mobile node has an IPv6 address it can use in a particular
>> routing realm as its roaming.  It will know as it roams it is moving to
>> a new routing realm.  The prefix of the routing realm changes and it
>> knows it has to use a new address to communicate in the new routing
>> realm or in wireless terms cell with new Base Station.
> 

>So the client is going to tell the server "I only want addresses with
>this prefix?"

Well basically but I would word it that the client mobile node tells the
server I am moving into this routing realm roaming and this is the
prefix of that realm.

>> But also under your model the client cannot renew lets say their global
>> address until the renewal timer goes off which is based on the
>> site-local address as 2X as an example.  The client has to wait 2X
>> before it can ask for a new lease or address for global communications.

>No, that's not right.   The renewal time is the minimum preferred
>lifetime for all the addresses in the identity association.  So the
>client *has* to renew the global address just as it becomes
>v6deprecated.

But how does it do that in that model.  From your mail the REQUEST could
not happen on the client until the rnewal timer went off as I read the
mail?

>> I believe the trade-off to permit the client to update individual
>> address lifetimes if the server permits it is worth it for the case wher
>> the client needs to update the lease even though their renewal has not
>> gone off.

>The client is also free to renew anytime it wants prior to the lease
>expiry, just like in DHCPv4.   So this doesn't seem like a problem.

If the client can renew anytime whats the point of the renewal timer?

>> How does the server do garbage collection then of IAs that are defunct
>> for some reason?  I don't want them sitting around in my database or
>> however I choose to implement the server config database?

>As soon as there are no valid addresses associated with an IA, you
>can gc the IA.

There is for the server database:

IA1
  config parameters provided and addresses
IA2
  config parameter provided and addresses 
IAn......

Today the only releaseable resources we have are addresses and once
those expire I can delete the IAx binding, if we can assume that any
future releaseable resources will have timers then that will work.  

>> The implementation reason is the same reason we balance binary trees
>> every now and then it reduces the search for the client when it comes to
>> the server.

>This makes sense.   In a high turnover environment, you'd want to be
>smart about harvesting stale IAs.   However, in an environment with
>a more consistent set of clients, which is the typical DHCPv4
>scenario, this isn't a real problem.   And in either case, I don't
>think there's any need for a special negotiation.

Possibly not I agree now.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 16:26:03 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24637
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 16:26:02 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8FKOvb06169;
	Fri, 15 Sep 2000 16:24:57 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8FKOpb25408
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 16:24:51 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a17.pm3-24.theriver.com [206.102.192.33]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id TAA15537 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 19:31:18 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8FKLKH02905 for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 13:21:21 -0700 (MST)
Message-Id: <200009152021.e8FKLKH02905@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Fri, 15 Sep 2000 15:19:39 -0400." <200009151919.PAA0000796189@anw.zk3.dec.com> 
Date: Fri, 15 Sep 2000 13:21:20 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Well I did get about 5 hours in.  And yep had that expresso machine out
> again....But seriously its very good to keep this debate going now if
> the editors are to get this next rev out per the schedule but I think we
> are slipping.

Yup.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 16:34:08 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24724
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 16:34:08 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8FKXSb28062;
	Fri, 15 Sep 2000 16:33:28 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8FKXPb28835
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 16:33:25 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 65204158D; Fri, 15 Sep 2000 16:33:10 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id 4C54A551E
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 16:33:10 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id QAA0000809457; Fri, 15 Sep 2000 16:32:57 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009152032.QAA0000809457@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Design team teleconference, 8/31 
In-reply-to: Your message of "Fri, 15 Sep 2000 09:09:16 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC164@lespaul.process.com> 
Date: Fri, 15 Sep 2000 16:32:56 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>So, perhaps we use the old "DISCOVER" message to perform this function
>(adding a new message to DHCPv6). Or, perhaps the DHCPSOLICIT can include an
>option that would say to the server give me some addreses.

I think we should add this to the solicit.

>How many DHCPv4 clients really take a look at what the server is offering
>and base a decision on whether to accept on that? I suspect most clients
>take the first offer they receive.

Also with advertise in dhcpv6 we now have preference field the client
can wait solicit_timers to get a certain number of responses.
We should add but I think the it must be made to not be the case for
mobile nodes.

Or we just make the default for preference 255 and that way the
administrators own changing it.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 16:40:39 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24759
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 16:40:38 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8FKe9b13890;
	Fri, 15 Sep 2000 16:40:09 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8FKdtb13936
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 16:39:55 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 2A66F11A3; Fri, 15 Sep 2000 15:39:34 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id C2C8413EF
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 15:39:33 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id QAA0000809671; Fri, 15 Sep 2000 16:39:32 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009152039.QAA0000809671@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Co nference Call Agenda) 
In-reply-to: Your message of "Fri, 15 Sep 2000 09:29:27 EDT."
             <4.3.1.2.20000915092521.00b92590@mail.bucknell.edu> 
Date: Fri, 15 Sep 2000 16:39:31 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>>I believe the general consensus was a desire to use the DHCPv4-style
>>reconfiguration (unicast from server to client).
>
>I agree.

But we did not discuss pro's and con's in the design meeting or have
rigorous debate and we don't have consensus on the mailing list yet.
Consensus was achieved without any discussion as that was the mind set for
the design meeting.

I also believe we MUST support multicast for existing IPv6 deployment
and for Dynamic Renumbering with DHCPv6.  Otherwise we have not done the
basics.

>  However, there is also a
>desire to accommondate multicasting as for major network reconfiguration
>events, unicasting may inefficient (if there are 1000's of clients to
>notify). But multicasting opens up significant security issues.

>I don't think multicast adds efficiency.  It only reduces the number of 
>messages by a constant factor (1/2 at best) and makes reliable 
>communication with clients significantly more difficult.  Security is also 
>a significant issue for multicast.

I don't agree.  It is far more efficient to send a multicast from a
server than 1000 unicast messages that is why IPv6 bases much of its
protocol on multicast.  

Can you state why you think it is difficult for implementation to do
this I don't think it is.

>We can always add multicast later...

But we need Multicast now, today.

I would like to hear what others think too?

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 17:28:52 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25126
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 17:28:51 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8FLQHb31104;
	Fri, 15 Sep 2000 17:26:17 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8FLQDb30565
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 17:26:13 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a17.pm3-24.theriver.com [206.102.192.33]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA15778 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 20:32:40 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8FLMbH03722 for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 14:22:38 -0700 (MST)
Message-Id: <200009152122.e8FLMbH03722@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Fri, 15 Sep 2000 16:10:34 -0400." <200009152010.QAA0000806898@anw.zk3.dec.com> 
Date: Fri, 15 Sep 2000 14:22:37 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> If we went down this path then we would want a way for the client to let
> the server know what it wants and I don't think we should do that and
> then we are heading back to the existing spec which I don't think is
> wrong but appears to be complex to get implementors excited.  But the
> real issue is why I want this and why it is innate to IPv6 Stateless
> Addrconf for which I think the DHCPv6 model should support.

I don't want this either - I proposed it because it sounded like you
wanted it.   I'm happy with the model Thomas described where the
server administrator determines what kind of addresses get given out,
and the client just has to deal with what it gets.

> But the point is that IPv6 endorses and assumes IPv6 nodes for one
> interface may want to have many many addresses of different scopes as I
> depict above and the IP6 architecture permits the behavior.  I believe
> DHCPv6 must all support that behavior and in fact DHCPv6 would be in
> error if it did not.

We are in resounding agreement here.

> So if you don't like this you don't like what IPv6 has done.

I just don't like the way the word is being used in IPv6.  I think the
concept to which it refers is the right thing - indeed, there are
cases right now where customers of mine would like this functionality
in IPv4.

So please don't mistake what I'm saying for griping about the protocol
- I'm just griping about the linguistic difficulties I'm running into
because words are being used in specialized ways and I'm too
specialized in a different direction to be aware of all the different
usages.  I basically just stepped in it in a big way using
"deprecated" the way I did initially.  Sigh.  :'}

> >No, that's not right.   The renewal time is the minimum preferred
> >lifetime for all the addresses in the identity association.  So the
> >client *has* to renew the global address just as it becomes
> >v6deprecated.
> 
> But how does it do that in that model.  From your mail the REQUEST could
> not happen on the client until the rnewal timer went off as I read the
> mail?

Right, and the renewal timer is on the identity association, not the
address, and it's the correct time to do a renewal given the addresses
in the identity association.   So by definition it is going to cause
the right thing to happen.

> >The client is also free to renew anytime it wants prior to the lease
> >expiry, just like in DHCPv4.   So this doesn't seem like a problem.
> 
> If the client can renew anytime whats the point of the renewal timer?

It is possible for the client to renew anytime - e.g., on reboot.  The
point of the renewal timer is to tell the client when it *must*
renew if it wants to keep its addresses.

> Today the only releaseable resources we have are addresses and once
> those expire I can delete the IAx binding, if we can assume that any
> future releaseable resources will have timers then that will work.  

Right.   If a releasable resource doesn't have a timeout, I think
you're stuck remembering the association anyway, at least until you
get a release event or the operator intervenes (shudder).   This
argues strongly in favour of never having releasable resources without
timeouts...  :'}



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 17:30:39 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25154
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 17:30:39 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8FLSMb04934;
	Fri, 15 Sep 2000 17:28:22 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8FLS9b02448
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 17:28:09 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a17.pm3-24.theriver.com [206.102.192.33]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA15784 for <dhcp-v6@bucknell.edu>; Thu, 14 Sep 2000 20:34:36 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8FLOYH03752 for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 14:24:34 -0700 (MST)
Message-Id: <200009152124.e8FLOYH03752@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Co nference Call Agenda) 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Fri, 15 Sep 2000 16:39:31 -0400." <200009152039.QAA0000809671@anw.zk3.dec.com> 
Date: Fri, 15 Sep 2000 14:24:34 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> >We can always add multicast later...
> But we need Multicast now, today.

On an intuitive level I agree with you on this, Jim.   I don't
understand what the objection is to multicast.   Can someone concisely
summarize what the problems are with implementing multicast
reconfigure?

Thanks!

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 15 21:01:49 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26476
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 15 Sep 2000 21:01:48 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8G0wvb10313;
	Fri, 15 Sep 2000 20:58:57 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8G0wkb09226
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 20:58:46 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 61D7C3F0D; Fri, 15 Sep 2000 20:58:31 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id 2947A3C52
	for <dhcp-v6@bucknell.edu>; Fri, 15 Sep 2000 20:58:31 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id UAA0000833649; Fri, 15 Sep 2000 20:57:45 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009160057.UAA0000833649@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: bound@ZK3.DEC.COM
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Fri, 15 Sep 2000 14:22:37 PDT."
             <200009152122.e8FLMbH03722@grosse.bisbee.fugue.com> 
Date: Fri, 15 Sep 2000 20:57:45 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>> But how does it do that in that model.  From your mail the REQUEST could
>> not happen on the client until the rnewal timer went off as I read the
>> mail?
>
>Right, and the renewal timer is on the identity association, not the
>address, and it's the correct time to do a renewal given the addresses
>in the identity association.   So by definition it is going to cause
>the right thing to happen.

Yes as you stated if the renewal timer is less than a preferred timer
mean that would work I agree.  And if the client don't see the address
then it knows the server has potentially released it then don't own it
anymore.  That would work.  This is progress.

>> >The client is also free to renew anytime it wants prior to the lease
>> >expiry, just like in DHCPv4.   So this doesn't seem like a problem.
>> 
>> If the client can renew anytime whats the point of the renewal timer?
>
>It is possible for the client to renew anytime - e.g., on reboot.  The
>point of the renewal timer is to tell the client when it *must*
>renew if it wants to keep its addresses.

OK but why is that different than the valid lifetime?  In IPv6 if the
valid timer goes off the connection gets broken.

I just want to be sure we have not maybe solved this timer problem with
the valid lifetime for an address.

But then we could say the renewal time is for the address set in total?

I can live with the client sending back all addresses when it wants to
renew the global address and that will work with the existing IPv6
Address Extension.  It does add extra bytes to the message and I think
we need to at least acknowledge that to a mobile node until we see 156kb
pedestrian throughput for mobile roaming there is a point where we do
need to reduce the bytes we won't see those speeds as I read the Tea
Leaves for Wireless till 2003 as a note.

I think it fair to ask the WG how they feel about this?

Do we try to save bytes for mobile nodes in DHCPv6?  I think we should
if its not too complex to implement which is the engineering trade-off.

Ted and others ????

>> Today the only releaseable resources we have are addresses and once
>> those expire I can delete the IAx binding, if we can assume that any
>> future releaseable resources will have timers then that will work.  
>
>Right.   If a releasable resource doesn't have a timeout, I think
>you're stuck remembering the association anyway, at least until you
>get a release event or the operator intervenes (shudder).   This
>argues strongly in favour of never having releasable resources without
>timeouts...  :'}

Yep thats where I was headed but I am sure somone on the list would tell
me that is too severe a limitation to state in DHCPv6 at this point and
we can always add that later.  But I think its a good statement about
releaseable resources.

regards,
/jim 



From owner-dhcp-v6@bucknell.edu  Sat Sep 16 03:17:51 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13021
	for <DHC-ARCHIVE@odin.ietf.org>; Sat, 16 Sep 2000 03:17:51 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8G7FLb11935;
	Sat, 16 Sep 2000 03:15:21 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8G7FDb26015
	for <dhcp-v6@bucknell.edu>; Sat, 16 Sep 2000 03:15:13 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a17.pm3-24.theriver.com [206.102.192.33]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id GAA19098; Fri, 15 Sep 2000 06:21:22 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8G7AMH10792; Sat, 16 Sep 2000 00:10:23 -0700 (MST)
Message-Id: <200009160710.e8G7AMH10792@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
cc: bound@ZK3.DEC.COM
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Fri, 15 Sep 2000 20:57:45 -0400." <200009160057.UAA0000833649@anw.zk3.dec.com> 
Date: Sat, 16 Sep 2000 00:10:22 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> OK but why is that different than the valid lifetime?  In IPv6 if the
> valid timer goes off the connection gets broken.

The identity association's renewal time is a construct, based on a
process of aggregating all the preferred times (probably) for all the
addresses in an identity association.  It exists so that you don't
have to renew addresses seperately, and secondarily so that you don't
send pointless renewal messages for non-renewable addresses.

> I just want to be sure we have not maybe solved this timer problem with
> the valid lifetime for an address.

I don't think so - the valid timer serves the purpose of making sure
that an address stops being used once it becomes invalid, and the
renewal timer causes renewal packets to be generated - two different,
albeit related, purposes.

> But then we could say the renewal time is for the address set in total?

Precisamento!   :')

> I can live with the client sending back all addresses when it wants to
> renew the global address and that will work with the existing IPv6
> Address Extension.  It does add extra bytes to the message and I think
> we need to at least acknowledge that to a mobile node until we see 156kb
> pedestrian throughput for mobile roaming there is a point where we do
> need to reduce the bytes we won't see those speeds as I read the Tea
> Leaves for Wireless till 2003 as a note.
> 
> I think it fair to ask the WG how they feel about this?
> 
> Do we try to save bytes for mobile nodes in DHCPv6?  I think we should
> if its not too complex to implement which is the engineering trade-off.

I think if you do the math it's not the clear cut, *particularly* for
a mobile node.  Let's say for simplicity (so we have to only talk
about one identity association) that you have a mobile node that's not
doing mobile IP - it's just changing its address from time to time as
it moves around, and doing short-lived transactions on the network.
And right now you're sitting in your office with it.   Let's say you
get a global address and a site-local address, and the server is
giving the global address a renewal time of 24 hours, but the site-
local address has a renewal time of a week.   So if you renew
addresses together, over a week period, you get this:

T+0d00h: DHCPsolicit+DHCPadvertise+DHCPrequest+DHCPreply
T+0d12h: DHCPrequest+DHCPreply
T+1d00h: DHCPrequest+DHCPreply
T+1d12h: DHCPrequest+DHCPreply
T+2d00h: DHCPrequest+DHCPreply
T+2d12h: DHCPrequest+DHCPreply
T+3d00h: DHCPrequest+DHCPreply
T+3d12h: DHCPrequest+DHCPreply
T+4d00h: DHCPrequest+DHCPreply
T+4d12h: DHCPrequest+DHCPreply
T+5d00h: DHCPrequest+DHCPreply
T+5d12h: DHCPrequest+DHCPreply
T+6d00h: DHCPrequest+DHCPreply
T+6d12h: DHCPrequest+DHCPreply
T+7d00h: DHCPrequest+DHCPreply

So you have 1 DHCPsolicit, 1 DHCPadvertise, 15 DHCPrequests and 15
DHCPreplies.  So using the current IP Address extension, each
DHCPreply contains 64 octets of address extensions, plus a minimal
IPv6 header of what, maybe 40 octets, 8 octets of UDP header, and
maybe 16 octets of framing, plus maybe another 64 octets of other
extensions, plus a 16-octet signature, for a total of 208 octets.  The
DHCPrequests, I'm not so sure about, but I'm not convinced that it is
going to be usual in a situation like this for them to contain
explicit address requests, so let's say they're more like 64 octets of
header, 16 octets of extensions and 16 octets of signature, for a
total of 96 octets.  The DHCPsolicit is probably roughly the same size
as the DHCPrequest - 96 octets.  The DHCPadvertise might be as large
as the DHCPreply - 208 octets.  So you have 16 208-octet packets and
16 96-octet packets.  So the total traffic size in this scenario is
4864 bytes.

Now consider your scenario - we have:

T+0d00h: DHCPsolicit+DHCPadvertise+DHCPrequest+DHCPreply for both addresses
T+0d12h: DHCPrequest+DHCPreply for global
T+1d00h: DHCPrequest+DHCPreply for global
T+1d12h: DHCPrequest+DHCPreply for global
T+2d00h: DHCPrequest+DHCPreply for global
T+2d12h: DHCPrequest+DHCPreply for global
T+3d00h: DHCPrequest+DHCPreply for global
T+3d12h: DHCPrequest+DHCPreply for global
T+4d00h: DHCPrequest+DHCPreply for global
T+4d12h: DHCPrequest+DHCPreply for global
T+5d00h: DHCPrequest+DHCPreply for global
T+5d12h: DHCPrequest+DHCPreply for global
T+6d00h: DHCPrequest+DHCPreply for global
T+6d12h: DHCPrequest+DHCPreply for global
T+7d00h: DHCPrequest+DHCPreply for global and site-local

So here you have one DHCPsolicit, one DHCPadvertise, 15 DHCPrequests
and two DHCPreplies that are the same size as in the previous
scenario, for 16x96+3x208.   Plus, you have 13 DHCPreplies that are
174 bytes, so this adds up to a total of 4422 bytes.

So the actual difference in traffic here is 442 bytes - about 10%.
And this is the *worst case scenario*, which you will almost never see
in the context of a roaming device in the real world.   It has a
site-local and global address with very different lifetimes, which is
unlikely in a mobile phone context in the first place.   It didn't
move around, so you didn't have to renew because of cell transitions.
If we'd been renewing on cell transitions, there's a good chance we
would have seen the same number of bytes in both cases, because the
renewals would have happened before either lifetime expired.

So I think in the real world, with a mobile device like a cell phone,
you are going to see no difference in bandwidth consumption.
Furthermore, the worst-case scenario I described is susceptible to
compression, and we might well want to specify a compression mechanism
for low-bandwidth mobile devices anyway.  This would probably burn
that 10% down to 1% - an "I didn't move" renewal is going to have a
tiny payload in both directions.

So I really think that the bandwidth argument isn't a good argument
against this scheme.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Sat Sep 16 21:19:48 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18488
	for <DHC-ARCHIVE@odin.ietf.org>; Sat, 16 Sep 2000 21:19:48 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8H1Gab21055;
	Sat, 16 Sep 2000 21:16:36 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8H1GXb13688
	for <dhcp-v6@bucknell.edu>; Sat, 16 Sep 2000 21:16:33 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8N1B8>; Sat, 16 Sep 2000 21:16:17 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC166@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 o
	n Co nference Call Agenda)
Date: Sat, 16 Sep 2000 21:16:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I agree with using multicast. I have no objection to its use.

I think the issue with the multicast has been that it opens up denial of
service attacks. Sending 1 message to mess up 1000s of clients is considered
bad (if you don't support multicast, a person attempting a DOS attack would
need to send 1000s of messages and need to know each clients address in
order to do that attack). The solution is pretty easy - require
authentication (of some level) especially with multicast.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Friday, September 15, 2000 5:25 PM
To: DHCPv6 discussion list
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18
on Co nference Call Agenda)



> >We can always add multicast later...
> But we need Multicast now, today.

On an intuitive level I agree with you on this, Jim.   I don't
understand what the objection is to multicast.   Can someone concisely
summarize what the problems are with implementing multicast
reconfigure?

Thanks!

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Sun Sep 17 00:08:59 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21455
	for <DHC-ARCHIVE@odin.ietf.org>; Sun, 17 Sep 2000 00:08:58 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8H46Hb06078;
	Sun, 17 Sep 2000 00:06:17 -0400 (EDT)
Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8H46Eb01352
	for <dhcp-v6@bucknell.edu>; Sun, 17 Sep 2000 00:06:14 -0400 (EDT)
Received: from leo (leo [134.82.56.108])
	by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id AAA22432
	for <dhcp-v6@bucknell.edu>; Sun, 17 Sep 2000 00:06:13 -0400 (EDT)
Date: Sun, 17 Sep 2000 00:06:13 -0400 (EDT)
From: "Ralph E. Droms" <droms@bucknell.edu>
X-Sender: droms@leo
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on
 Co nference Call Agenda) 
In-Reply-To: <200009152124.e8FLOYH03752@grosse.bisbee.fugue.com>
Message-ID: <Pine.GSO.4.03.10009162337110.22395-100000@leo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


On Fri, 15 Sep 2000, Ted Lemon wrote:
> > >We can always add multicast later...
> > But we need Multicast now, today.
> 
> On an intuitive level I agree with you on this, Jim.   I don't
> understand what the objection is to multicast.   Can someone concisely
> summarize what the problems are with implementing multicast
> reconfigure?


In any event, multicast is intuitively appealing.  But the devil appears
to be in the details.  I hope this summary is both concise and precise...

Using multicast for Reconfigure-init, triggering clients to send a Solicit
message, only saves 1/5 of the total messages; i.e., the multicast
Reconfigure-init causes each client to initiate a four-message exchange
with the server.  If each client has a server to contact (either its
initial server or the server that generated the Reconfigure-init or some
other server specified in the Reconfigure-init message),then each client
might be able to use a two-message exchange.  In that case, multicast
would save 1/3 of the total messages.

Simple multicast does not scale well.  A multicast Reconfigure-init would
cause a flood of messages to be sent to the server.  This problem can be
ameliorated with the use of randomization on the part of clients, or by
use of different multicast addresses for different groups of clients.
Either of these solutions adds complexity to the multicast specification.

Finally, authentication is a problem.  The multicasting server must be
able to authenticate itself to all of the clients, using a single
authenticator value in the Reconfigure-init message.  I don't believe
we've addressed this problem in any of the proposals for multicast-based
reconfigure.

- Ralph




From owner-dhcp-v6@bucknell.edu  Sun Sep 17 15:44:48 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11168
	for <DHC-ARCHIVE@odin.ietf.org>; Sun, 17 Sep 2000 15:44:48 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8HJgKb13487;
	Sun, 17 Sep 2000 15:42:21 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8HJg5b31313
	for <dhcp-v6@bucknell.edu>; Sun, 17 Sep 2000 15:42:05 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-207.ip.theriver.com [206.97.58.207]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id SAA24261 for <dhcp-v6@bucknell.edu>; Sat, 16 Sep 2000 18:48:30 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8HJbbV01223 for <dhcp-v6@bucknell.edu>; Sun, 17 Sep 2000 12:37:38 -0700 (MST)
Message-Id: <200009171937.e8HJbbV01223@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Co nference Call Agenda) 
In-Reply-To: Message from "Ralph E. Droms" <droms@bucknell.edu> 
   of "Sun, 17 Sep 2000 00:06:13 -0400." <Pine.GSO.4.03.10009162337110.22395-100000@leo> 
Date: Sun, 17 Sep 2000 12:37:37 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> In any event, multicast is intuitively appealing.  But the devil appears
> to be in the details.  I hope this summary is both concise and precise...

Yup.   The authentication problem kills it.   Thanks for delving into
that.   Based on what you've said, I think we should scrap multicast
for now.   :'(

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Sun Sep 17 22:29:06 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14249
	for <DHC-ARCHIVE@odin.ietf.org>; Sun, 17 Sep 2000 22:29:05 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8I2Qeb29934;
	Sun, 17 Sep 2000 22:26:40 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8I2O3b28766
	for <dhcp-v6@bucknell.edu>; Sun, 17 Sep 2000 22:24:03 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id C32071E59; Sun, 17 Sep 2000 21:52:55 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP
	id 2F96B1FB6; Sun, 17 Sep 2000 21:52:55 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id VAA0000632576; Sun, 17 Sep 2000 21:52:40 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009180152.VAA0000632576@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: dhcp-v6@bucknell.edu
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Sat, 16 Sep 2000 00:10:22 PDT."
             <200009160710.e8G7AMH10792@grosse.bisbee.fugue.com> 
Date: Sun, 17 Sep 2000 21:52:40 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>So I really think that the bandwidth argument isn't a good argument
>against this scheme.

Nice work on that.  I agree.  Also another datapoint is that stateful
addrconf for IPv6 hopefully is not happening as often say using the web
via wap or something.

I am fine with the renewal time strategy.

thanks
/jim



From owner-dhcp-v6@bucknell.edu  Sun Sep 17 22:29:26 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14260
	for <DHC-ARCHIVE@odin.ietf.org>; Sun, 17 Sep 2000 22:29:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8I2O5b31999;
	Sun, 17 Sep 2000 22:24:05 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8I2Nxb31457
	for <dhcp-v6@bucknell.edu>; Sun, 17 Sep 2000 22:23:59 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id 4332910C6; Sun, 17 Sep 2000 21:23:44 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id B805D10A6
	for <dhcp-v6@bucknell.edu>; Sun, 17 Sep 2000 21:23:43 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id WAA0000635988; Sun, 17 Sep 2000 22:23:42 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009180223.WAA0000635988@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Co nference Call Agenda) 
In-reply-to: Your message of "Sun, 17 Sep 2000 00:06:13 EDT."
             <Pine.GSO.4.03.10009162337110.22395-100000@leo> 
Date: Sun, 17 Sep 2000 22:23:41 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>Using multicast for Reconfigure-init, triggering clients to send a Solicit
>message, only saves 1/5 of the total messages; i.e., the multicast
>Reconfigure-init causes each client to initiate a four-message exchange
>with the server.  If each client has a server to contact (either its
>initial server or the server that generated the Reconfigure-init or some
>other server specified in the Reconfigure-init message),then each client
>might be able to use a two-message exchange.  In that case, multicast
>would save 1/3 of the total messages.

1/3 of bandwidth is pretty good though on a network.  But there is
another benefit besides bandwidth coservation but performance.  If an
admin must trigger an emergency renumbering event or a military
field operation wants to notify 2000 wireless clients of a parameter
then this is where Multicast is also far more efficient and will perform
far better than 2000 unicast messages.  The server can be configured
quite large with multiple interfaces and processors to handle such
returned traffic and its done today with many server applications with
such a load (not necessarily multicast).  

>Simple multicast does not scale well.  A multicast Reconfigure-init would
>cause a flood of messages to be sent to the server.  This problem can be
>ameliorated with the use of randomization on the part of clients, or by
>use of different multicast addresses for different groups of clients.
>Either of these solutions adds complexity to the multicast specification.

I don't believe it does not scale?  Unless you believe that multicast
does not scale as a general technology as some do?  I believe multicast
is far superior to unicast for many operations.  But the complexity I
don't see at all.  This is from dhcpv6-15 and I don't believe it to be
complex at all?

!12.4.2. Time out and retransmission of Reconfigure messages
!
!
!   The server waits RECREP_MSG_TIMEOUT milliseconds, collecting
!   Reconfigure-reply messages.  If all the expected Reconfigure-reply
!   messages are received, then the reconfigure process is successful.
!   If some or all of the expected Reconfigure-reply messages are not
!   received, then the server retransmits the Reconfigure, and doubles
!   the RECREP_MSG_TIMEOUT value, and waits again.  The server continues
!  this process until all Reconfigure-reply messages are received or
!   REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which time
!  the server SHOULD abort the reconfigure process.  The server SHOULD
!   log the result of the reconfigure process.
!
!
!   Default and initial values for RECREP_MSG_TIMEOUT and
!   REC_MSG_ATTEMPTS are documented in section 3.5.


>Finally, authentication is a problem.  The multicasting server must be
>able to authenticate itself to all of the clients, using a single
>authenticator value in the Reconfigure-init message.  I don't believe
>we've addressed this problem in any of the proposals for multicast-based
>reconfigure.

Reconfigure only works if the client has a global address.
In that case IPsec can be used with a generic Authentication key for
reconfigure each client can have for this purpose.

We can also recommend that Reconfigure multicast should only be used on 
an Intranet until security ramifications across the Internet are better
understood.

regards,
/jim

- Ralph



From owner-dhcp-v6@bucknell.edu  Sun Sep 17 23:17:26 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15496
	for <DHC-ARCHIVE@odin.ietf.org>; Sun, 17 Sep 2000 23:17:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8I31ub21686;
	Sun, 17 Sep 2000 23:01:56 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8I31pb17572
	for <dhcp-v6@bucknell.edu>; Sun, 17 Sep 2000 23:01:51 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 971BE1EE9; Sun, 17 Sep 2000 23:01:35 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id 0A1A01EB9
	for <dhcp-v6@bucknell.edu>; Sun, 17 Sep 2000 23:01:34 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id XAA0000639229; Sun, 17 Sep 2000 23:01:19 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009180301.XAA0000639229@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Francis's INput at the Design Meeting
Date: Sun, 17 Sep 2000 23:01:19 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I want to state I am now thinking Francis's input at the meeting may
make sense.  Maybe this should not even be called DHCP but Stateful
Address Configuration for IPv6 (SACv6).

Also I am far more concerned about integration with IPv6 Statless
Addrconf than DHCPv4 as a DHCPv6 implementor?

How many dhcpv4 implementors have looked at the ND daemon to do
stateless addrconf and the code?  We want to reuse much from that as
IPv6 implementors as possbile.

If you don't have access to an IPv6 stateless address conf
implementation I am sure Francis's code can be viewed as I think its
public domain.

Also it could be we have multiple views of Stateful addrconf too.
Not that its a good idea but if we don't support IPv6 first in every
manner that will happen.

regards,
/jim



From owner-dhcp-v4@bucknell.edu  Sun Sep 17 23:54:13 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16103
	for <DHC-ARCHIVE@odin.ietf.org>; Sun, 17 Sep 2000 23:54:07 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8I3kPb28597;
	Sun, 17 Sep 2000 23:46:26 -0400 (EDT)
Received: from web9009.mail.yahoo.com ([216.136.128.171])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8I3kDb13500
	for <dhcp-v4@bucknell.edu>; Sun, 17 Sep 2000 23:46:13 -0400 (EDT)
Message-ID: <20000918034557.54553.qmail@web9009.mail.yahoo.com>
Received: from [146.163.222.129] by web9009.mail.yahoo.com; Sun, 17 Sep 2000 20:45:57 PDT
Date: Sun, 17 Sep 2000 20:45:57 -0700 (PDT)
From: rvp valipi <rvpnet@yahoo.com>
Subject: IP length
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Reply-To: rvpnet@yahoo.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

hi,
     i work with an freebsd/windows 98 system with an
DHCP SERVER configured in the network.
everything was fine until today, suddenly when boot
from freebsd partition,my dhcp client is not able to
get it's parameters and ip address from the
server.from the boot messages i confer that DHCP is
offering one.these are the boot messages i'm getting,

DHCPDISCOVER 
ip length 360 disagrees with bytes received 374 int4
accepted packet with data after UDP payload.
DHCPOFFER 146.163.1.4
DHCPOFFER 146.163.1.4
DHCPREQUEST
.................

and this sems to be continuing for ever.

could someone please suggest me in solving the
problem.
there seems to no problem when i boot from windows 98.

Thank,

raghuram
 

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 03:34:42 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29413
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 03:34:41 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8I7W7b29608;
	Mon, 18 Sep 2000 03:32:07 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8I7W5b03201
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 03:32:05 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-207.ip.theriver.com [206.97.58.207]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA00581 for <dhcp-v6@bucknell.edu>; Sat, 16 Sep 2000 20:56:39 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8I4ijV07734 for <dhcp-v6@bucknell.edu>; Sun, 17 Sep 2000 21:44:46 -0700 (MST)
Message-Id: <200009180444.e8I4ijV07734@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Francis's INput at the Design Meeting 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Sun, 17 Sep 2000 23:01:19 -0400." <200009180301.XAA0000639229@anw.zk3.dec.com> 
Date: Sun, 17 Sep 2000 21:44:45 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> I want to state I am now thinking Francis's input at the meeting may
> make sense.  Maybe this should not even be called DHCP but Stateful
> Address Configuration for IPv6 (SACv6).

I can see where you're coming from, but this is kind of like saying
"let's call it toasted wheat crumbs instead of Grape Nuts" at this
point.   :'}

> Also I am far more concerned about integration with IPv6 Statless
> Addrconf than DHCPv4 as a DHCPv6 implementor?

Right, but what about your customers?   If you want to really
differentiate between DHCPv4 and DHCPv6 because there's some
important functional difference between the true, then confusing the
customers is probably a good thing, but if DHCPv6 is going to have
similar uses to DHCPv4, keeping the name the same makes more sense.

> How many dhcpv4 implementors have looked at the ND daemon to do
> stateless addrconf and the code?  We want to reuse much from that as
> IPv6 implementors as possbile.

What's an ND Daemon?

> Also it could be we have multiple views of Stateful addrconf too.
> Not that its a good idea but if we don't support IPv6 first in every
> manner that will happen.

I think ideally we should make it possible for people to get what they
want by layering on a good base protocol rather than inventing new
ones.   That's what we're trying to do here, right?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 10:42:11 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09249
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 10:42:09 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IEd2b31607;
	Mon, 18 Sep 2000 10:39:02 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IEclb10648
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 10:38:47 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8N1RZ>; Mon, 18 Sep 2000 10:38:31 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC16C@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Francis's INput at the Design Meeting
Date: Mon, 18 Sep 2000 10:38:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I'm for keeping the DHCPv6 name. Agreed that it is Stateful, but remember
that the V6 people didn't call it DHCP for a reason - they wanted to
potentially support any (multiple) stateful protocols/techniques.

This also could be included in Ralph's issue of what to call the message
names? If we're going to use the DHCPv4 names, why would we than want to
call is SAC? If we're not going to use the DHCPv4 names (which I am in favor
of), perhaps it is open to further discussion whether this should be DHCPv6
or SAC. But again I feel DHCPv6 is far better as it is based on DHCPv4 and
takes into account new features of IPv6.

ND Daemon is a Neighbor Discovery daemon, I suspect. I think Jim feels that
DHCPv6 (client side) is really part of the ND Daemon that handles all
addressing issues (whether stateful or not).

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Monday, September 18, 2000 12:45 AM
To: DHCPv6 discussion list
Subject: Re: Francis's INput at the Design Meeting



> I want to state I am now thinking Francis's input at the meeting may
> make sense.  Maybe this should not even be called DHCP but Stateful
> Address Configuration for IPv6 (SACv6).

I can see where you're coming from, but this is kind of like saying
"let's call it toasted wheat crumbs instead of Grape Nuts" at this
point.   :'}

> Also I am far more concerned about integration with IPv6 Statless
> Addrconf than DHCPv4 as a DHCPv6 implementor?

Right, but what about your customers?   If you want to really
differentiate between DHCPv4 and DHCPv6 because there's some
important functional difference between the true, then confusing the
customers is probably a good thing, but if DHCPv6 is going to have
similar uses to DHCPv4, keeping the name the same makes more sense.

> How many dhcpv4 implementors have looked at the ND daemon to do
> stateless addrconf and the code?  We want to reuse much from that as
> IPv6 implementors as possbile.

What's an ND Daemon?

> Also it could be we have multiple views of Stateful addrconf too.
> Not that its a good idea but if we don't support IPv6 first in every
> manner that will happen.

I think ideally we should make it possible for people to get what they
want by layering on a good base protocol rather than inventing new
ones.   That's what we're trying to do here, right?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 11:56:12 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12190
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 11:56:12 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IFqdb26837;
	Mon, 18 Sep 2000 11:52:39 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IFqMb06061
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 11:52:23 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 66A8A1E1F; Mon, 18 Sep 2000 11:52:03 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id 460761DCA
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 11:52:03 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id LAA0000713760; Mon, 18 Sep 2000 11:51:50 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009181551.LAA0000713760@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Francis's INput at the Design Meeting 
In-reply-to: Your message of "Mon, 18 Sep 2000 10:38:30 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC16C@lespaul.process.com> 
Date: Mon, 18 Sep 2000 11:51:50 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

good response bernie but mostly I feel francis's input was not discussed
or his issues from the con call and we need to keep this process open to
all input and francis went silent and is the only one on this list that
has written dhcpv6 code I am aware of except for me.  so I am trying to
entice him back to the discussion I think he got annoyed from the con
call.

thanks,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 12:03:06 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12332
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 12:03:06 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IG29b17639;
	Mon, 18 Sep 2000 12:02:09 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IG25b00632
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 12:02:05 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 53A126FBE; Mon, 18 Sep 2000 12:01:50 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id D12996DB0
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 12:01:47 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id MAA0000714821; Mon, 18 Sep 2000 12:01:47 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009181601.MAA0000714821@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: bound@ZK3.DEC.COM
Subject: Re: Francis's INput at the Design Meeting 
In-reply-to: Your message of "Sun, 17 Sep 2000 21:44:45 PDT."
             <200009180444.e8I4ijV07734@grosse.bisbee.fugue.com> 
Date: Mon, 18 Sep 2000 12:01:47 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>> Also I am far more concerned about integration with IPv6 Statless
>> Addrconf than DHCPv4 as a DHCPv6 implementor?
>
>Right, but what about your customers?   If you want to really
>differentiate between DHCPv4 and DHCPv6 because there's some
>important functional difference between the true, then confusing the
>customers is probably a good thing, but if DHCPv6 is going to have
>similar uses to DHCPv4, keeping the name the same makes more sense.

DHCP name is fine with me I just wanted Francis's input discussed like
yours, mine, and ralphs I really don't care what the name is and I don't
think my customers do.  But dhcpv6 is not dhcpv4 and IPv6 has enough
parts that make it completely different.


>> How many dhcpv4 implementors have looked at the ND daemon to do
>> stateless addrconf and the code?  We want to reuse much from that as
>> IPv6 implementors as possbile.

>What's an ND Daemon?

Neighbor Discovery Daemon.  Processes Ipv6 stateless parts and will know
if dhcpv6 should be started.

>> Also it could be we have multiple views of Stateful addrconf too.
>> Not that its a good idea but if we don't support IPv6 first in every
>> manner that will happen.
>
>I think ideally we should make it possible for people to get what they
>want by layering on a good base protocol rather than inventing new
>ones.   That's what we're trying to do here, right?

Yes and that good protocol is IPv6 stateless not dhcpv4 as the model.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 12:06:12 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12434
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 12:06:12 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IG5Rb08735;
	Mon, 18 Sep 2000 12:05:27 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IG56b05196
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 12:05:06 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id 486182B9A; Mon, 18 Sep 2000 11:04:49 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 7D44728E8
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 11:04:49 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id MAA0000714492; Mon, 18 Sep 2000 12:04:48 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009181604.MAA0000714492@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: renewal time
Date: Mon, 18 Sep 2000 12:04:48 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

for the renewal time?  should we pass this in the packets or just use
algorithm to determine the time in the spec.  mike and I are beginning
to edit the specs.

personally I don't care but if we can save bytes in the packet and keep
msgs shorter that would be good and one of things we were told people
wanted from dhcpv6.

thanks
/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 12:38:52 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14114
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 12:38:52 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IGZlb30190;
	Mon, 18 Sep 2000 12:35:47 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IGZbb19017
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 12:35:37 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8N1ZN>; Mon, 18 Sep 2000 12:35:17 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC170@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: renewal time
Date: Mon, 18 Sep 2000 12:35:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Jim:

Can you clarify what you mean? Are you proposing to base the renewal time on
an address lifetime? Or, are you referring to the T1/T2 times like in
DHCPv4?

I'd vote to pass a "lease time" in the packets. The renewal times (if we use
T1/T2 values as in DHCPv4) can be set in the spec (with options/extensions
to override defaults if a site needs it).

- Bernie

-----Original Message-----
From: Jim Bound [mailto:bound@zk3.dec.com]
Sent: Monday, September 18, 2000 12:05 PM
To: DHCPv6 discussion list
Subject: renewal time


for the renewal time?  should we pass this in the packets or just use
algorithm to determine the time in the spec.  mike and I are beginning
to edit the specs.

personally I don't care but if we can save bytes in the packet and keep
msgs shorter that would be good and one of things we were told people
wanted from dhcpv6.

thanks
/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 12:43:59 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14351
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 12:43:58 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IGgub26465;
	Mon, 18 Sep 2000 12:42:56 -0400 (EDT)
Received: from lychee.itojun.org (206-175-32-114.vpnworkshop.com [206.175.32.114])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IGgjb25609
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 12:42:45 -0400 (EDT)
Received: from kiwi.itojun.org (localhost [127.0.0.1])
	by itojun.org (8.10.0/3.7W) with ESMTP id e8IGgRr01195
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 01:42:27 +0900 (JST)
Message-Id: <200009181642.e8IGgRr01195@itojun.org>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Francis's INput at the Design Meeting 
X-Template-Reply-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Date: Tue, 19 Sep 2000 01:42:27 +0900
From: Jun-ichiro itojun Hagino <itojun@ITOJUN.ORG>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

	sorry, this is a resend (due to From: filter)

------- Forwarded Message

To: dhcp-v6@bucknell.edu
cc: bound@ZK3.DEC.COM
In-reply-to: bound's message of Mon, 18 Sep 2000 12:01:47 -0400.
      <200009181601.MAA0000714821@anw.zk3.dec.com> 
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: Francis's INput at the Design Meeting 
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Date: Tue, 19 Sep 2000 01:15:59 +0900
Sender: itojun@localhost


>>> How many dhcpv4 implementors have looked at the ND daemon to do
>>> stateless addrconf and the code?  We want to reuse much from that as
>>> IPv6 implementors as possbile.
>>What's an ND Daemon?
>Neighbor Discovery Daemon.  Processes Ipv6 stateless parts and will know
>if dhcpv6 should be started.

	the above discussion/comment looks very implementation dependent for me.
	(maybe I don't have enough context with me - sorry if this is the case)

	there are people implementing ND in the kernel (for example
	KAME/NRL, just like BSD did for IPv4 ARP), and there are people
	implementing ND in the userand (for example INRIA, grab ND messages
	via ICMPv6 socket).  I have not seen other implementation in detail
	enough, but my feeling is that kernel ND implementation is more common
	at this moment.

	independent from where ND is implemented, we need to have some
	interaction between ND code and DHCPv6 code, in terms of "M" bit
	on RA message.  here are couple of examples:
	- (kernel ND implementation) inform of the existence of "M" bit
	  via some signal or whatever
	- (kernel ND implementation) DHCPv6 client code watches RA message
	  by itself, by listening to an ICMPv6 socket
	- (userland ND implementation) implement DHCPv6 client and stateless
	  autoconf into a single daemon.
	- (userland ND implementation) define inter process communication
	  between DHCPv6 client daemon and stateless autoconf daemon

itojun

------- End of Forwarded Message



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 14:36:17 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17049
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 14:36:15 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IIWvb21813;
	Mon, 18 Sep 2000 14:32:57 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IIWgb28141
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 14:32:42 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a40.pm3-32.theriver.com [206.102.192.104]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id HAA03593 for <dhcp-v6@bucknell.edu>; Sun, 17 Sep 2000 07:57:15 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8IIWSw01102 for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 11:32:35 -0700 (MST)
Message-Id: <200009181832.e8IIWSw01102@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: renewal time 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Mon, 18 Sep 2000 12:04:48 -0400." <200009181604.MAA0000714492@anw.zk3.dec.com> 
Date: Mon, 18 Sep 2000 11:32:28 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> for the renewal time?  should we pass this in the packets or just use
> algorithm to determine the time in the spec.  mike and I are beginning
> to edit the specs.

I don't think there's a good technical reason to have the server
calculate the renewal time.   The only reason I suggest having the
server do it is that it's less likely that the implementor will screw
up their implementation and release a client that gets into renewal
storms when one of its addresses becomes non-renewable.   Based on my
experience in IPv4 land, I actually think this is a strong enough
reason to justify the additional 64 bytes from the server.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 14:48:24 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17303
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 14:48:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IIm4b19929;
	Mon, 18 Sep 2000 14:48:04 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IIlob21161
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 14:47:50 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id C6C692473; Mon, 18 Sep 2000 13:47:33 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP
	id 6838627EA; Mon, 18 Sep 2000 13:47:33 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id OAA0000733107; Mon, 18 Sep 2000 14:47:20 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009181847.OAA0000733107@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: dhcp-v6@bucknell.edu, bound@ZK3.DEC.COM, bound@ZK3.DEC.COM
Subject: Re: Francis's INput at the Design Meeting 
In-reply-to: Your message of "Tue, 19 Sep 2000 01:15:59 +0900."
             <200009181616.e8IGG0r01028@itojun.org> 
Date: Mon, 18 Sep 2000 14:47:20 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>>>> How many dhcpv4 implementors have looked at the ND daemon to do
>>>> stateless addrconf and the code?  We want to reuse much from that as
>>>> IPv6 implementors as possbile.
>>>What's an ND Daemon?
>>Neighbor Discovery Daemon.  Processes Ipv6 stateless parts and will know
>>if dhcpv6 should be started.

>	the above discussion/comment looks very implementation dependent for me.
>	(maybe I don't have enough context with me - sorry if this is the case)

It was just for discussion.  Yes it can be in the kernel or user space.

	independent from where ND is implemented, we need to have some
	interaction between ND code and DHCPv6 code, in terms of "M" bit
	on RA message.  here are couple of examples:
	- (kernel ND implementation) inform of the existence of "M" bit
	  via some signal or whatever
	- (kernel ND implementation) DHCPv6 client code watches RA message
	  by itself, by listening to an ICMPv6 socket
	- (userland ND implementation) implement DHCPv6 client and stateless
	  autoconf into a single daemon.
	- (userland ND implementation) define inter process communication
	  between DHCPv6 client daemon and stateless autoconf daemon

Correct.  What we don't want to do is make this interaction difficult
with the spec.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 14:54:22 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17304
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 14:48:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IIiob01226;
	Mon, 18 Sep 2000 14:44:50 -0400 (EDT)
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IIikb28354
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 14:44:47 -0400 (EDT)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA28036
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 14:44:27 -0400
Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA29712
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 14:44:28 -0400
Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA32274 for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 14:41:52 -0400
Message-Id: <200009181841.OAA32274@rotala.raleigh.ibm.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Francis's INput at the Design Meeting 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Sun, 17 Sep 2000 23:01:19 EDT." <200009180301.XAA0000639229@anw.zk3.dec.com> 
Date: Mon, 18 Sep 2000 14:41:52 -0400
From: Thomas Narten <narten@RALEIGH.IBM.COM>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

> I want to state I am now thinking Francis's input at the meeting may
> make sense.  Maybe this should not even be called DHCP but Stateful
> Address Configuration for IPv6 (SACv6).

The above title wouldn't seem to be consistent with DHCP being used to
send configuration parameters other than addresses (e.g., server
addresses, time zone info, etc.).

Thomas



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 14:55:03 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17411
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 14:55:02 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IIsUb05568;
	Mon, 18 Sep 2000 14:54:30 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IIsOb31527
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 14:54:25 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 1BDBC2B6D; Mon, 18 Sep 2000 14:54:09 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id 003AF2AE3
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 14:54:08 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id OAA0000734054; Mon, 18 Sep 2000 14:54:08 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009181854.OAA0000734054@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: renewal time 
In-reply-to: Your message of "Mon, 18 Sep 2000 12:35:06 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC170@lespaul.process.com> 
Date: Mon, 18 Sep 2000 14:54:08 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>Can you clarify what you mean? Are you proposing to base the renewal time on
>an address lifetime? Or, are you referring to the T1/T2 times like in
>DHCPv4?

It was the Ted/Jim discussion thread.  I view the renewal time like the
T1/T2 times in DCHPv4.

>I'd vote to pass a "lease time" in the packets. The renewal times (if we use
>T1/T2 values as in DHCPv4) can be set in the spec (with options/extensions
>to override defaults if a site needs it).

This would be my suggestion too.  The lease time (preferred and valid
times) have to be in the packet like we have in the existing address
extension.  

What Ted is proposing is the client only can send a REQUEST when the
renewal timer goes off or that is how will work as it is based on the
least value of preferred timers.  This will work.  So in that sense its
like the T1 and T2 but adds to DHCPv6 when the client will REQUEST new
addresses.  If we do this I think we can do it with a defined algorithm
for the client in the spec.  Mike and I can make first pass at it to
get a spec out per the deadline.  Is what I was asking.

But I should ask? 

Do other folks not agree with the renewal time strategy so far we have
really only heard from Ralph, Ted, and me?  That's hardly consensus, and
not trying to force this but trying to get a spec for us to discuss by
early october or sept 30th.

Bernie what do you think?
Francis what do you think?
others.....what do you think?

thanks
/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 15:02:45 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17573
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 15:02:44 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IJ1wb14315;
	Mon, 18 Sep 2000 15:01:58 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IJ1lb15524
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 15:01:48 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NFCA>; Mon, 18 Sep 2000 15:01:31 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC173@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: renewal time
Date: Mon, 18 Sep 2000 15:01:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Jim, I agree with the renewal time strategy.

I do agree with Ted that the server should send it:

	I don't think there's a good technical reason to have the server
	calculate the renewal time.   The only reason I suggest having the
	server do it is that it's less likely that the implementor will
screw
	up their implementation and release a client that gets into renewal
	storms when one of its addresses becomes non-renewable.   Based on
my
	experience in IPv4 land, I actually think this is a strong enough
	reason to justify the additional 64 bytes from the server.

- Bernie Volz

-----Original Message-----
From: Jim Bound [mailto:bound@zk3.dec.com]
Sent: Monday, September 18, 2000 2:54 PM
To: DHCPv6 discussion list
Subject: Re: renewal time



>Can you clarify what you mean? Are you proposing to base the renewal time
on
>an address lifetime? Or, are you referring to the T1/T2 times like in
>DHCPv4?

It was the Ted/Jim discussion thread.  I view the renewal time like the
T1/T2 times in DCHPv4.

>I'd vote to pass a "lease time" in the packets. The renewal times (if we
use
>T1/T2 values as in DHCPv4) can be set in the spec (with options/extensions
>to override defaults if a site needs it).

This would be my suggestion too.  The lease time (preferred and valid
times) have to be in the packet like we have in the existing address
extension.  

What Ted is proposing is the client only can send a REQUEST when the
renewal timer goes off or that is how will work as it is based on the
least value of preferred timers.  This will work.  So in that sense its
like the T1 and T2 but adds to DHCPv6 when the client will REQUEST new
addresses.  If we do this I think we can do it with a defined algorithm
for the client in the spec.  Mike and I can make first pass at it to
get a spec out per the deadline.  Is what I was asking.

But I should ask? 

Do other folks not agree with the renewal time strategy so far we have
really only heard from Ralph, Ted, and me?  That's hardly consensus, and
not trying to force this but trying to get a spec for us to discuss by
early october or sept 30th.

Bernie what do you think?
Francis what do you think?
others.....what do you think?

thanks
/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 15:05:25 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17656
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 15:05:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IJ4pb02301;
	Mon, 18 Sep 2000 15:04:51 -0400 (EDT)
Received: from mail02-oak.pilot.net (mail-oak-2.pilot.net [198.232.147.17])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IJ4Zb06226
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 15:04:36 -0400 (EDT)
Received: from mail01-gap.gap.com ([206.24.101.33]) by mail02-oak.pilot.net with ESMTP id MAA27737 for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 12:04:31 -0700 (PDT)
From: Relfe_Tan@gap.com
Received: from mailhub02.gap.com ([9.32.202.152]) by mail01-gap.gap.com with ESMTP id MAA23946 for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 12:04:30 -0700 (PDT)
Received: from smtpmta01.gap.com (smtpmta01.gap.com [9.30.201.43])
	by mailhub02.gap.com (Pro-8.9.3/Pro-8.9.3) with SMTP id MAA12329
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 12:03:23 -0700 (PDT)
Received: by smtpmta01.gap.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 8825695E.006859DF ; Mon, 18 Sep 2000 11:59:47 -0700
X-Lotus-FromDomain: GAPINC
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Message-ID: <8825695E.00684D81.00@smtpmta01.gap.com>
Date: Mon, 18 Sep 2000 11:57:22 -0700
Subject: unsubscribe
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


How do I unscrubscibe"
<Unsubscribe>



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 15:12:40 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17825
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 15:12:39 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IJ9xb12338;
	Mon, 18 Sep 2000 15:09:59 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IJ9jb03930
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 15:09:45 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 865E11ED0; Mon, 18 Sep 2000 15:09:29 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id 707491EF6
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 15:09:29 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id PAA0000735453; Mon, 18 Sep 2000 15:09:29 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009181909.PAA0000735453@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: renewal time 
In-reply-to: Your message of "Mon, 18 Sep 2000 15:01:27 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC173@lespaul.process.com> 
Date: Mon, 18 Sep 2000 15:09:28 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

bernie,

OK.. I am going to go with you and Ted then?  thats 3 of us.
????? others ????

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 15:27:12 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18033
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 15:27:11 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IJN0b19582;
	Mon, 18 Sep 2000 15:23:00 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IJMob26205
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 15:22:51 -0400 (EDT)
Received: from mjs-pc (mjs-pc.cisco.com [172.27.181.69]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA23687 for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 15:22:31 -0400 (EDT)
Message-Id: <4.2.0.58.20000918151338.033f7b70@funnel.cisco.com>
X-Sender: mjs@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 18 Sep 2000 15:23:06 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Mark Stapp <mjs@cisco.com>
Subject: Re: renewal time 
In-Reply-To: <200009181854.OAA0000734054@anw.zk3.dec.com>
References: <Your message of "Mon, 18 Sep 2000 12:35:06 EDT." <63D30D6E10CFD11190A90000F805FE8602BEC170@lespaul.process.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


I agree that there should be renewal time defaults in the protocol itself, 
but that the server should be able to send extension data which overrides 
those defaults. That's how I read the messages from Bernie and Ted. But 
this paragraph of Jim's confused me a bit:

>What Ted is proposing is the client only can send a REQUEST when the
>renewal timer goes off or that is how will work as it is based on the
>least value of preferred timers.  This will work.  So in that sense its
>like the T1 and T2 but adds to DHCPv6 when the client will REQUEST new
>addresses.  If we do this I think we can do it with a defined algorithm
>for the client in the spec.  Mike and I can make first pass at it to
>get a spec out per the deadline.  Is what I was asking.

Jim - when you say "when the client will REQUEST new addresses", do you 
really mean _new_ addresses, as in _additional_ addresses? I think you mean 
something like "will REQUEST that the server extend the lease-times 
associated with a client-id": is that correct, or do you really mean "new 
addresses"?

-- Mark


At 02:54 PM 9/18/00 -0400, Jim Bound wrote:

> >Can you clarify what you mean? Are you proposing to base the renewal time on
> >an address lifetime? Or, are you referring to the T1/T2 times like in
> >DHCPv4?
>
>It was the Ted/Jim discussion thread.  I view the renewal time like the
>T1/T2 times in DCHPv4.
>
> >I'd vote to pass a "lease time" in the packets. The renewal times (if we use
> >T1/T2 values as in DHCPv4) can be set in the spec (with options/extensions
> >to override defaults if a site needs it).
>
>This would be my suggestion too.  The lease time (preferred and valid
>times) have to be in the packet like we have in the existing address
>extension.
>
>What Ted is proposing is the client only can send a REQUEST when the
>renewal timer goes off or that is how will work as it is based on the
>least value of preferred timers.  This will work.  So in that sense its
>like the T1 and T2 but adds to DHCPv6 when the client will REQUEST new
>addresses.  If we do this I think we can do it with a defined algorithm
>for the client in the spec.  Mike and I can make first pass at it to
>get a spec out per the deadline.  Is what I was asking.
>
>But I should ask?
>
>Do other folks not agree with the renewal time strategy so far we have
>really only heard from Ralph, Ted, and me?  That's hardly consensus, and
>not trying to force this but trying to get a spec for us to discuss by
>early october or sept 30th.
>
>Bernie what do you think?
>Francis what do you think?
>others.....what do you think?
>
>thanks
>/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 15:59:23 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18684
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 15:59:21 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IJuKb21909;
	Mon, 18 Sep 2000 15:56:20 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IJu2b27402
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 15:56:02 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a40.pm3-32.theriver.com [206.102.192.104]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id JAA03847 for <dhcp-v6@bucknell.edu>; Sun, 17 Sep 2000 09:20:35 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8IJtnw02247 for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 12:55:49 -0700 (MST)
Message-Id: <200009181955.e8IJtnw02247@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: renewal time 
In-Reply-To: Message from Mark Stapp <mjs@cisco.com> 
   of "Mon, 18 Sep 2000 15:23:06 -0400." <4.2.0.58.20000918151338.033f7b70@funnel.cisco.com> 
Date: Mon, 18 Sep 2000 12:55:49 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Jim - when you say "when the client will REQUEST new addresses", do you 
> really mean _new_ addresses, as in _additional_ addresses? I think you mean 
> something like "will REQUEST that the server extend the lease-times 
> associated with a client-id": is that correct, or do you really mean "new 
> addresses"?

I think the right phrase here is something like "request the renewal
of the addresses in the identity association."

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 15:59:37 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18696
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 15:59:35 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IJtib13662;
	Mon, 18 Sep 2000 15:55:44 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IJtfb24287
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 15:55:42 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a40.pm3-32.theriver.com [206.102.192.104]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id JAA03843 for <dhcp-v6@bucknell.edu>; Sun, 17 Sep 2000 09:20:12 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8IJtBw02232 for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 12:55:26 -0700 (MST)
Message-Id: <200009181955.e8IJtBw02232@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: renewal time 
In-Reply-To: Message from Mark Stapp <mjs@cisco.com> 
   of "Mon, 18 Sep 2000 15:23:06 -0400." <4.2.0.58.20000918151338.033f7b70@funnel.cisco.com> 
Date: Mon, 18 Sep 2000 12:55:11 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> I agree that there should be renewal time defaults in the protocol itself, 
> but that the server should be able to send extension data which overrides 
> those defaults. That's how I read the messages from Bernie and Ted. But 
> this paragraph of Jim's confused me a bit:

Actually, what I'm saying is that the server should always send this,
not that it should be permitted to.   Otherwise the client has to be
prepared to compute the renewal time.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 16:42:25 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19416
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 16:42:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IKdJb17292;
	Mon, 18 Sep 2000 16:39:19 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IKd4b04461
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 16:39:04 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (sj-dial-3-67.cisco.com [171.68.180.68]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA03935 for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 16:38:43 -0400 (EDT)
Message-Id: <4.3.1.2.20000918104739.00b7b810@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 18 Sep 2000 06:23:25 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9,
  18 on Conference Call Agenda) 
In-Reply-To: <200009180223.WAA0000635988@anw.zk3.dec.com>
References: <Your message of "Sun, 17 Sep 2000 00:06:13 EDT." <Pine.GSO.4.03.10009162337110.22395-100000@leo>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 10:23 PM 9/17/00 -0400, Jim Bound wrote:

>1/3 of bandwidth is pretty good though on a network.

The computer scientist in me says 1/3 is only a constant factor and doesn't 
contribute to scalability...


>I don't believe it does not scale?  Unless you believe that multicast
>does not scale as a general technology as some do?

I would hesitate to apply the observation that "multicast scales as a 
general technology" to this specific case without working through the 
details.  I think there is question about whether reliable multicast scales...

As to the complexity of multicast reconfigure, I still believe the devil is 
in the details.  The text you cited in 12.4.2, for example, does not 
address the question of how a client responds to a retransmitted 
reconfigure message.  Does the client try to detect retransmitted 
reconfigure messages?  If so, does the client respond only to the first 
reconfigure message and ignore retransmitted reconfigure messages?  Suppose 
the client's reconfigure-reply message is lost - how does the client know 
that it should respond to a retransmitted reconfigure message?

These problems could be solved with a mixed multicast/unicast strategy - 
multicast the first reconfigure message and unicast any retransmitted 
reconfigure messages.  For this to work, the client behavior should, I 
think, be specified to be "respond to every reconfigure regardless of 
whether it has been retransmitted".

- Ralph




From owner-dhcp-v6@bucknell.edu  Mon Sep 18 16:54:22 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19415
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 16:42:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IKdUb18323;
	Mon, 18 Sep 2000 16:39:30 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IKdFb19796
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 16:39:15 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (sj-dial-3-67.cisco.com [171.68.180.68]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA03946 for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 16:38:50 -0400 (EDT)
Message-Id: <4.3.1.2.20000918104438.00b7c2b0@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 18 Sep 2000 07:46:51 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: Francis's INput at the Design Meeting
In-Reply-To: <200009180301.XAA0000639229@anw.zk3.dec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 11:01 PM 9/17/00 -0400, you wrote:
>I want to state I am now thinking Francis's input at the meeting may
>make sense.  Maybe this should not even be called DHCP but Stateful
>Address Configuration for IPv6 (SACv6).

I had thought about making a similar observation, given that the current 
draft is not trying to reuse DHCPv4 technology.  However, we have a spec to 
get out, as quickly as possible, and diving into a discussion about 
renaming will, in my opinion, slow down the work on the spec.

- Ralph



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 18:41:39 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20945
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 18:41:37 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8IMcbb24403;
	Mon, 18 Sep 2000 18:38:37 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8IMcSb10769
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 18:38:28 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NFMF>; Mon, 18 Sep 2000 18:38:11 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC178@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 o
	n Conference Call Agenda)
Date: Mon, 18 Sep 2000 18:38:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

>These problems could be solved with a mixed multicast/unicast strategy - 
>multicast the first reconfigure message and unicast any retransmitted 
>reconfigure messages.  For this to work, the client behavior should, I 
>think, be specified to be "respond to every reconfigure regardless of 
>whether it has been retransmitted".

You might also solve them by:
- Having the client remember the "transaction id" / server source address
and dropping any reconfigure messages with the same transaction id received
within some time period (several minutes?). Of course, all subsequent
retransmitted reconfigure messages MUST use the same "transaction id".
- Having the client ignore additional multicast reconfigure messages (on the
same interface) for some time period after receiving one (again, several
minutes). This method has the added benefit that fake messages can't
repeatedly trigger reconfigurations except at some reasonable slow rate. Of
coures, it makes multiple renumbering events take longer (but that they'd
occur within minutes of each other is rather unlikely anyway).

I do think the technique in 12.4.2 is somewhat flawed anyway since if one or
more clients are down, the "expected" number of messages may never be
returned.

I think a better server strategy is to multicast several Reconfigure
messages several seconds apart (this presumes that a client hopefully won't
miss all if it is up and on the network). Then, if any clients fail to
respond within the alloted time, those clients are sent unicast packets.
(Perhaps the server can also make a determination of how many clients failed
to response and if it exceeds some threshold (>50?), it MAY multicast again
with the same transaction-id).

- Bernie Volz


-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Monday, September 18, 2000 6:23 AM
To: DHCPv6 discussion list
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18
on Conference Call Agenda)


At 10:23 PM 9/17/00 -0400, Jim Bound wrote:

>1/3 of bandwidth is pretty good though on a network.

The computer scientist in me says 1/3 is only a constant factor and doesn't 
contribute to scalability...


>I don't believe it does not scale?  Unless you believe that multicast
>does not scale as a general technology as some do?

I would hesitate to apply the observation that "multicast scales as a 
general technology" to this specific case without working through the 
details.  I think there is question about whether reliable multicast
scales...

As to the complexity of multicast reconfigure, I still believe the devil is 
in the details.  The text you cited in 12.4.2, for example, does not 
address the question of how a client responds to a retransmitted 
reconfigure message.  Does the client try to detect retransmitted 
reconfigure messages?  If so, does the client respond only to the first 
reconfigure message and ignore retransmitted reconfigure messages?  Suppose 
the client's reconfigure-reply message is lost - how does the client know 
that it should respond to a retransmitted reconfigure message?

These problems could be solved with a mixed multicast/unicast strategy - 
multicast the first reconfigure message and unicast any retransmitted 
reconfigure messages.  For this to work, the client behavior should, I 
think, be specified to be "respond to every reconfigure regardless of 
whether it has been retransmitted".

- Ralph



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 21:18:34 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22524
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 21:18:32 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8J1Eqb03033;
	Mon, 18 Sep 2000 21:14:52 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8J1Eab03303
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 21:14:38 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 115EF2518; Mon, 18 Sep 2000 20:14:20 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 8DB3E27C4
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 20:14:19 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id VAA0000771501; Mon, 18 Sep 2000 21:14:05 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009190114.VAA0000771501@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: renewal time 
In-reply-to: Your message of "Mon, 18 Sep 2000 15:23:06 EDT."
             <4.2.0.58.20000918151338.033f7b70@funnel.cisco.com> 
Date: Mon, 18 Sep 2000 21:14:04 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>Jim - when you say "when the client will REQUEST new addresses", do you 
>really mean _new_ addresses, as in _additional_ addresses? I think you mean 
>something like "will REQUEST that the server extend the lease-times 
>associated with a client-id": is that correct, or do you really mean "new 
>addresses"?

Correct new lease-times or the Server could not give the client an
address back meaning its expired too.  But no new addresses.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 21:45:04 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23668
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 21:45:02 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8J1hnb08688;
	Mon, 18 Sep 2000 21:43:49 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8J1hbb13230
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 21:43:37 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 713721E1E; Mon, 18 Sep 2000 20:43:20 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 2BA5325D6
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 20:43:20 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id VAA0000774309; Mon, 18 Sep 2000 21:43:18 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009190143.VAA0000774309@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Conference Call Agenda) 
In-reply-to: Your message of "Mon, 18 Sep 2000 06:23:25 EDT."
             <4.3.1.2.20000918104739.00b7b810@mail.bucknell.edu> 
Date: Mon, 18 Sep 2000 21:43:18 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>>1/3 of bandwidth is pretty good though on a network.
>
>The computer scientist in me says 1/3 is only a constant factor and doesn't 
>contribute to scalability...

OK.  Sounds like discussion over a beverage but I see your point.

>>I don't believe it does not scale?  Unless you believe that multicast
>>does not scale as a general technology as some do?
>
>I would hesitate to apply the observation that "multicast scales as a 
>general technology" to this specific case without working through the 
>details.  I think there is question about whether reliable multicast scales...

OK.  As a comment I am convinced multicast is good and the whole world
should be using it and I even read Steve Deering's Phd Thesis while
drinking good wine :----)...

>As to the complexity of multicast reconfigure, I still believe the devil is 
>in the details.  The text you cited in 12.4.2, for example, does not 
>address the question of how a client responds to a retransmitted 
>reconfigure message.  Does the client try to detect retransmitted 
>reconfigure messages?  If so, does the client respond only to the first 
>reconfigure message and ignore retransmitted reconfigure messages?  Suppose 
>the client's reconfigure-reply message is lost - how does the client know 
>that it should respond to a retransmitted reconfigure message?

Yep.  The scenarios we used to have got dropped in the last draft.

The client should only respond to the first multicast for X time then we
have to let them respond again when X ends.  This will provide some
scalability for the reconfigure-init. 

>These problems could be solved with a mixed multicast/unicast strategy - 
>multicast the first reconfigure message and unicast any retransmitted 
>reconfigure messages.  For this to work, the client behavior should, I 
>think, be specified to be "respond to every reconfigure regardless of 
>whether it has been retransmitted".

That would work and quite elegant really (nice idea).  It also
eliminates what I said above.  It also addresses my main reason for the
feature to tell clients to listen up in real network emergency type
situation or serious changes need to be done site or Intranet wide.

My fear on this one is if we don't put it in now I fear it will never
get in too.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 18 21:46:30 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23688
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 18 Sep 2000 21:46:28 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8J1jWb16026;
	Mon, 18 Sep 2000 21:45:32 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8J1jSb04773
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 21:45:29 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id D895E1469; Mon, 18 Sep 2000 21:45:11 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id C0B821DC5
	for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 21:45:11 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id VAA0000774325; Mon, 18 Sep 2000 21:45:10 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009190145.VAA0000774325@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Francis's INput at the Design Meeting 
In-reply-to: Your message of "Mon, 18 Sep 2000 07:46:51 EDT."
             <4.3.1.2.20000918104438.00b7c2b0@mail.bucknell.edu> 
Date: Mon, 18 Sep 2000 21:45:10 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>At 11:01 PM 9/17/00 -0400, you wrote:
>>I want to state I am now thinking Francis's input at the meeting may
>>make sense.  Maybe this should not even be called DHCP but Stateful
>>Address Configuration for IPv6 (SACv6).
>
>I had thought about making a similar observation, given that the current 
>draft is not trying to reuse DHCPv4 technology.  However, we have a spec to 
>get out, as quickly as possible, and diving into a discussion about 
>renaming will, in my opinion, slow down the work on the spec.

I agree and as Thomas pointed out the above only means addresses.
No discussion on name changes I have ever seen is fast.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Tue Sep 19 01:47:00 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02518;
	Tue, 19 Sep 2000 01:47:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8J5i1b04419;
	Tue, 19 Sep 2000 01:44:05 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8J5i0b04407
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 01:44:00 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a40.pm3-32.theriver.com [206.102.192.104]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id TAA05085 for <dhcp-v6@bucknell.edu>; Sun, 17 Sep 2000 19:08:26 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8J5gNw09441 for <dhcp-v6@bucknell.edu>; Mon, 18 Sep 2000 22:42:24 -0700 (MST)
Message-Id: <200009190542.e8J5gNw09441@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: renewal time 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Mon, 18 Sep 2000 21:14:04 -0400." <200009190114.VAA0000771501@anw.zk3.dec.com> 
Date: Mon, 18 Sep 2000 22:42:23 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Correct new lease-times or the Server could not give the client an
> address back meaning its expired too.  But no new addresses.

Well, but if we're renumbering, the server might well give back a "new
address", right?  I think the point is that that client isn't asking
the server to do this - it's asking the server to renew.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Tue Sep 19 09:12:24 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14869;
	Tue, 19 Sep 2000 09:12:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JD9Wb05061;
	Tue, 19 Sep 2000 09:09:32 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JD9Mb15411
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 09:09:22 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (sj-dial-3-212.cisco.com [171.68.180.213]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA06182 for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 09:09:05 -0400 (EDT)
Message-Id: <4.3.1.2.20000919060451.00b811c0@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 19 Sep 2000 06:07:49 -0700
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: renewal time 
In-Reply-To: <200009190542.e8J5gNw09441@grosse.bisbee.fugue.com>
References: <Message from Jim Bound <bound@ZK3.DEC.COM>
 <200009190114.VAA0000771501@anw.zk3.dec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I've been thinking of the action associated with renewal as the client 
asking the server "Tell me what addresses are in this IA now and how long I 
can use them".  If the preferred/valid times have changed, it's like a 
lease extension.  If a renumbering event is in progress, the server can 
assign new addresses.  In any event, the server - based on all the 
information the server has about the client - is informing the client of 
the addresses currently in the IA

- Ralph

At 10:42 PM 9/18/00 -0700, Ted Lemon wrote:

> > Correct new lease-times or the Server could not give the client an
> > address back meaning its expired too.  But no new addresses.
>
>Well, but if we're renumbering, the server might well give back a "new
>address", right?  I think the point is that that client isn't asking
>the server to do this - it's asking the server to renew.




From owner-dhcp-v6@bucknell.edu  Tue Sep 19 09:38:08 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15345;
	Tue, 19 Sep 2000 09:38:08 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JDbcb06106;
	Tue, 19 Sep 2000 09:37:38 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JDbTb25391
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 09:37:29 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (sj-dial-3-212.cisco.com [171.68.180.213]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA09788 for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 09:37:11 -0400 (EDT)
Message-Id: <4.3.1.2.20000919062909.00ae96e0@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 19 Sep 2000 06:39:34 -0700
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: <200009160710.e8G7AMH10792@grosse.bisbee.fugue.com>
References: <Message from Jim Bound <bound@ZK3.DEC.COM>
 <200009160057.UAA0000833649@anw.zk3.dec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Let me see if I can successfully summarize the address model we've been 
discussing:

DHCP clients and servers will use Identity Associations (IAs) to manage 
IPv6 addresses.  Each IA will have:

* a unique identifier
* a set of IPv6 addresses
* a renewal time

Clients and servers use the unique identifier to identify the IAs in 
protocol messages.

Each IPv6 has an associated preferred and valid lifetime.  The lifetimes 
are determined by the server and handed to the client.  There are no 
restrictions on the scopes or number of IPv6 addresses in an IA; an IA 
might contain just one IPv6 address or it might contain a collection of 
global-, site- and link-local addresses.

The renewal time defines the time at which the client must contact the 
server to get the current state of the IA (call this "renewing" the 
IA).  The renewal time is independent of the address lifetimes of any of 
the lifetimes of the IPv6 addresses in the IA.  It makes most sense for the 
renewal time to be less than the valid lifetimes of all of the IPv6 
addresses in the IA.

When the client renews an IA, the server tells the client about the current 
set of IPv6 addresses in the IA.  The server may change the set of 
addresses or the lifetimes of existing addresses during this renewal.  For 
example, setting a longer lifetime on an address already in the IA is the 
equivalent of extending the lease on a DHCPv4-managed address.  Leaving an 
address out of an IA marks it immediately as no longer valid for the 
client.  Adding a new address to the IA can be used for renumbering.  In 
any event, the server is authoritative about the set of addresses and 
lifetimes in the IA.

- Ralph

At 09:10 PM 9/15/00 -0700, you wrote:

> > OK but why is that different than the valid lifetime?  In IPv6 if the
> > valid timer goes off the connection gets broken.
>
>The identity association's renewal time is a construct, based on a
>process of aggregating all the preferred times (probably) for all the
>addresses in an identity association.  It exists so that you don't
>have to renew addresses seperately, and secondarily so that you don't
>send pointless renewal messages for non-renewable addresses.
>
> > I just want to be sure we have not maybe solved this timer problem with
> > the valid lifetime for an address.
>
>I don't think so - the valid timer serves the purpose of making sure
>that an address stops being used once it becomes invalid, and the
>renewal timer causes renewal packets to be generated - two different,
>albeit related, purposes.
>
> > But then we could say the renewal time is for the address set in total?
>
>Precisamento!   :')
>
> > I can live with the client sending back all addresses when it wants to
> > renew the global address and that will work with the existing IPv6
> > Address Extension.  It does add extra bytes to the message and I think
> > we need to at least acknowledge that to a mobile node until we see 156kb
> > pedestrian throughput for mobile roaming there is a point where we do
> > need to reduce the bytes we won't see those speeds as I read the Tea
> > Leaves for Wireless till 2003 as a note.
> >
> > I think it fair to ask the WG how they feel about this?
> >
> > Do we try to save bytes for mobile nodes in DHCPv6?  I think we should
> > if its not too complex to implement which is the engineering trade-off.
>
>I think if you do the math it's not the clear cut, *particularly* for
>a mobile node.  Let's say for simplicity (so we have to only talk
>about one identity association) that you have a mobile node that's not
>doing mobile IP - it's just changing its address from time to time as
>it moves around, and doing short-lived transactions on the network.
>And right now you're sitting in your office with it.   Let's say you
>get a global address and a site-local address, and the server is
>giving the global address a renewal time of 24 hours, but the site-
>local address has a renewal time of a week.   So if you renew
>addresses together, over a week period, you get this:
>
>T+0d00h: DHCPsolicit+DHCPadvertise+DHCPrequest+DHCPreply
>T+0d12h: DHCPrequest+DHCPreply
>T+1d00h: DHCPrequest+DHCPreply
>T+1d12h: DHCPrequest+DHCPreply
>T+2d00h: DHCPrequest+DHCPreply
>T+2d12h: DHCPrequest+DHCPreply
>T+3d00h: DHCPrequest+DHCPreply
>T+3d12h: DHCPrequest+DHCPreply
>T+4d00h: DHCPrequest+DHCPreply
>T+4d12h: DHCPrequest+DHCPreply
>T+5d00h: DHCPrequest+DHCPreply
>T+5d12h: DHCPrequest+DHCPreply
>T+6d00h: DHCPrequest+DHCPreply
>T+6d12h: DHCPrequest+DHCPreply
>T+7d00h: DHCPrequest+DHCPreply
>
>So you have 1 DHCPsolicit, 1 DHCPadvertise, 15 DHCPrequests and 15
>DHCPreplies.  So using the current IP Address extension, each
>DHCPreply contains 64 octets of address extensions, plus a minimal
>IPv6 header of what, maybe 40 octets, 8 octets of UDP header, and
>maybe 16 octets of framing, plus maybe another 64 octets of other
>extensions, plus a 16-octet signature, for a total of 208 octets.  The
>DHCPrequests, I'm not so sure about, but I'm not convinced that it is
>going to be usual in a situation like this for them to contain
>explicit address requests, so let's say they're more like 64 octets of
>header, 16 octets of extensions and 16 octets of signature, for a
>total of 96 octets.  The DHCPsolicit is probably roughly the same size
>as the DHCPrequest - 96 octets.  The DHCPadvertise might be as large
>as the DHCPreply - 208 octets.  So you have 16 208-octet packets and
>16 96-octet packets.  So the total traffic size in this scenario is
>4864 bytes.
>
>Now consider your scenario - we have:
>
>T+0d00h: DHCPsolicit+DHCPadvertise+DHCPrequest+DHCPreply for both addresses
>T+0d12h: DHCPrequest+DHCPreply for global
>T+1d00h: DHCPrequest+DHCPreply for global
>T+1d12h: DHCPrequest+DHCPreply for global
>T+2d00h: DHCPrequest+DHCPreply for global
>T+2d12h: DHCPrequest+DHCPreply for global
>T+3d00h: DHCPrequest+DHCPreply for global
>T+3d12h: DHCPrequest+DHCPreply for global
>T+4d00h: DHCPrequest+DHCPreply for global
>T+4d12h: DHCPrequest+DHCPreply for global
>T+5d00h: DHCPrequest+DHCPreply for global
>T+5d12h: DHCPrequest+DHCPreply for global
>T+6d00h: DHCPrequest+DHCPreply for global
>T+6d12h: DHCPrequest+DHCPreply for global
>T+7d00h: DHCPrequest+DHCPreply for global and site-local
>
>So here you have one DHCPsolicit, one DHCPadvertise, 15 DHCPrequests
>and two DHCPreplies that are the same size as in the previous
>scenario, for 16x96+3x208.   Plus, you have 13 DHCPreplies that are
>174 bytes, so this adds up to a total of 4422 bytes.
>
>So the actual difference in traffic here is 442 bytes - about 10%.
>And this is the *worst case scenario*, which you will almost never see
>in the context of a roaming device in the real world.   It has a
>site-local and global address with very different lifetimes, which is
>unlikely in a mobile phone context in the first place.   It didn't
>move around, so you didn't have to renew because of cell transitions.
>If we'd been renewing on cell transitions, there's a good chance we
>would have seen the same number of bytes in both cases, because the
>renewals would have happened before either lifetime expired.
>
>So I think in the real world, with a mobile device like a cell phone,
>you are going to see no difference in bandwidth consumption.
>Furthermore, the worst-case scenario I described is susceptible to
>compression, and we might well want to specify a compression mechanism
>for low-bandwidth mobile devices anyway.  This would probably burn
>that 10% down to 1% - an "I didn't move" renewal is going to have a
>tiny payload in both directions.
>
>So I really think that the bandwidth argument isn't a good argument
>against this scheme.
>
>                                _MelloN_



From owner-dhcp-v6@bucknell.edu  Tue Sep 19 11:49:49 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18269;
	Tue, 19 Sep 2000 11:49:47 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JFkSb13892;
	Tue, 19 Sep 2000 11:46:28 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JFkMb24362
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 11:46:23 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id D30382529; Tue, 19 Sep 2000 10:46:05 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 62D79156C
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 10:46:05 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id LAA0000539338; Tue, 19 Sep 2000 11:46:04 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009191546.LAA0000539338@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Tue, 19 Sep 2000 06:39:34 PDT."
             <4.3.1.2.20000919062909.00ae96e0@mail.bucknell.edu> 
Date: Tue, 19 Sep 2000 11:46:04 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>The renewal time defines the time at which the client must contact the 
>server to get the current state of the IA (call this "renewing" the 
>IA).  The renewal time is independent of the address lifetimes of any of 
>the lifetimes of the IPv6 addresses in the IA.  It makes most sense for the 
>renewal time to be less than the valid lifetimes of all of the IPv6 
>addresses in the IA.

SHould be less than the preferred times.

>When the client renews an IA, the server tells the client about the current 
>set of IPv6 addresses in the IA.  The server may change the set of 
>addresses or the lifetimes of existing addresses during this renewal.  For 
>example, setting a longer lifetime on an address already in the IA is the 
>equivalent of extending the lease on a DHCPv4-managed address.  Leaving an 
>address out of an IA marks it immediately as no longer valid for the 
>client.  Adding a new address to the IA can be used for renumbering.  In 
>any event, the server is authoritative about the set of addresses and 
>lifetimes in the IA.

Have to watch for DOS attacks as in IPv6 Stateless where router sends
zero valid lifetimes with Router Advertisement.  Also if a server does
not return an address which may have valid lifetime left and telnet
running the connection will be broken as a note.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Tue Sep 19 18:18:32 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25618;
	Tue, 19 Sep 2000 18:18:30 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JMDMb02233;
	Tue, 19 Sep 2000 18:13:24 -0400 (EDT)
Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JMDEb28297
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 18:13:14 -0400 (EDT)
Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142])
	by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA12450
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 15:12:49 -0700 (PDT)
Date: Tue, 19 Sep 2000 15:12:49 -0700 (PDT)
From: Indrajanti Sukiman <isukiman@cisco.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Q on DHCPv6 draft (draft-ietf-dhc-dhcpv6-15.txt)
Message-ID: <Pine.GSO.4.10.10009191010510.22320-100000@sigma.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


In the draft-ietf-dhc-dhcpv6-15.txt, in sections related to message
validation (section 11.1, 11.2, 11.3), there are 'MUST' requirements that
agents (server and relay) discard messages which do not contain a 'valid
link-local address'. 

My question is, what is the definition of 'a not valid link-local address'?
Or, in other words, how would agents perform this verification ?
As far as I can tell, RFC2462 defines an invalid link-local address as an
address whose valid lifetime has expired. If this is the definition
intended, is there a way e.g. for a DHCPv6 server to know the valid
lifetime of the link-local address of a remote (several hops away) DHCPv6
client ? 

Thank you. 

-- Indrajanti Sukiman










From owner-dhcp-v6@bucknell.edu  Tue Sep 19 18:31:37 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25780;
	Tue, 19 Sep 2000 18:31:35 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JMUbb30336;
	Tue, 19 Sep 2000 18:30:37 -0400 (EDT)
Received: from cisco.com (flipper.cisco.com [171.69.25.141])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JMUIb12736
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 18:30:23 -0400 (EDT)
Received: from kitab.cisco.com (kitab.cisco.com [171.69.187.233])
	by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id PAA00928
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 15:30:00 -0700 (PDT)
Received: (from raj@localhost)
	by kitab.cisco.com (8.9.3/8.9.2) id PAA01899;
	Tue, 19 Sep 2000 15:30:32 -0700 (PDT)
	(envelope-from raj)
From: Richard Johnson <raj@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14791.59656.53565.277312@kitab.cisco.com>
Date: Tue, 19 Sep 2000 15:30:32 -0700 (PDT)
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Q on DHCPv6 draft (draft-ietf-dhc-dhcpv6-15.txt)
In-Reply-To: <Pine.GSO.4.10.10009191010510.22320-100000@sigma.cisco.com>
References: <Pine.GSO.4.10.10009191010510.22320-100000@sigma.cisco.com>
X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs  Lucid
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

Indrajanti Sukiman writes:
 > My question is, what is the definition of 'a not valid link-local address'?
 > Or, in other words, how would agents perform this verification ?
 > As far as I can tell, RFC2462 defines an invalid link-local address as an
 > address whose valid lifetime has expired. If this is the definition
 > intended, is there a way e.g. for a DHCPv6 server to know the valid
 > lifetime of the link-local address of a remote (several hops away) DHCPv6
 > client ? 

I feel sure what's meant is the definition from rfc1884.txt:

   2.4.8 Local-use IPv6 Unicast Addresses

   There are two types of local-use unicast addresses defined.  These
   are Link-Local and Site-Local.  The Link-Local is for use on a single
   link and the Site-Local is for use in a single site.  Link-Local
   addresses have the following format:

    |   10     |
    |  bits    |        n bits           |       118-n bits           |
    +----------+-------------------------+----------------------------+
    |1111111010|           0             |       interface ID         |
    +----------+-------------------------+----------------------------+

   Link-Local addresses are designed to be used for addressing on a
   single link for purposes such as auto-address configuration, neighbor
   discovery, or when no routers are present.

   Routers MUST not forward any packets with link-local source
   addresses.



From owner-dhcp-v6@bucknell.edu  Tue Sep 19 18:34:15 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25824;
	Tue, 19 Sep 2000 18:34:12 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JMXJb06189;
	Tue, 19 Sep 2000 18:33:19 -0400 (EDT)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JMXBb01852
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 18:33:11 -0400 (EDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e8JMWsu14996
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 00:32:54 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id AAA04756
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 00:32:53 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id AAA22797
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 00:34:41 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200009192234.AAA22797@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Francis's INput at the Design Meeting 
In-reply-to: Your message of Mon, 18 Sep 2000 10:38:30 EDT.
             <63D30D6E10CFD11190A90000F805FE8602BEC16C@lespaul.process.com> 
Date: Wed, 20 Sep 2000 00:34:41 +0200
Sender: owner-dhcp-v6@bucknell.edu
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Francis.Dupont@enst-bretagne.fr
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

 In your previous mail you wrote:

   I'm for keeping the DHCPv6 name.

=> the name doesn't really matter but:
 - IMHO it is important to understand DHCPv6 is more the statefull version
   of IPv6 autoconfiguration than the IPv6 version of DHCP, ie. it is
   supposed to add management to the existing stateless autoconf, not
   to do things which are exotic (for IPv6) or already done by other
   tools (like some service discovery).
 - formally the name DHCPv6 is wrong because it will apply to routers
   too (in fact, DHCPv6 is more useful for routers than for hosts because
   stateless autoconf works only for hosts). This point should be made
   clear in the new draft.

   ND Daemon is a Neighbor Discovery daemon, I suspect.

=> yes, ND is the nick name of Neighbor Discovery. Prefix discovery and
address autoconfiguration are two of the nine functions of ND.

   I think Jim feels that DHCPv6 (client side) is really part of the
   ND Daemon that handles all addressing issues (whether stateful or
   not).
   
=> the code managing the stateless autoconf must interoperate with
the DHCPv6 client. An easy way to do this is to manage both in an
user daemon.

Regards

Francis.Dupont@enst-bretagne.fr



From owner-dhcp-v6@bucknell.edu  Tue Sep 19 18:54:38 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26076;
	Tue, 19 Sep 2000 18:54:35 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JMpZb06865;
	Tue, 19 Sep 2000 18:51:35 -0400 (EDT)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JMpPb05433
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 18:51:25 -0400 (EDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e8JMp9u26074
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 00:51:10 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id AAA04891
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 00:51:06 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id AAA22858
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 00:52:54 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200009192252.AAA22858@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Francis's INput at the Design Meeting 
In-reply-to: Your message of Mon, 18 Sep 2000 14:41:52 EDT.
             <200009181841.OAA32274@rotala.raleigh.ibm.com> 
Date: Wed, 20 Sep 2000 00:52:53 +0200
Sender: owner-dhcp-v6@bucknell.edu
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Francis.Dupont@enst-bretagne.fr
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

 In your previous mail you wrote:

   > I want to state I am now thinking Francis's input at the meeting may
   > make sense.  Maybe this should not even be called DHCP but Stateful
   > Address Configuration for IPv6 (SACv6).
   
   The above title wouldn't seem to be consistent with DHCP being used to
   send configuration parameters other than addresses (e.g., server
   addresses, time zone info, etc.).
   
=> but is this really the job of DHCPv6? As soon as a node gets some
not too local addresses it can use any service discovery protocol.
IMHO it is not a good idea to overload DHCPv6 with secondary config
tasks, ie. DHCPv6 should only manage addresses, DNS and security
(security because of IPsec usage of destination addresses for SAs,
DNS because we have no good lightweight/zeroconf DNS tools today).

Francis.Dupont@enst-bretagne.fr

PS: a part of DHCPv6 complexity, for instance relays or reconfigure, has
no meaning if DHCPv6 is used for service discovery or parameter
distribution. I don't ask to split DHCPv6 in two protocols because
in fact service discovery and parameter distribution protocols already
exist, they just don't work well with off-link nodes without routable
addresses.



From owner-dhcp-v6@bucknell.edu  Tue Sep 19 19:05:06 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26197;
	Tue, 19 Sep 2000 19:05:04 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8JN4Ab20345;
	Tue, 19 Sep 2000 19:04:10 -0400 (EDT)
Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8JN43b25100
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 19:04:04 -0400 (EDT)
Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142])
	by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA20425
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 16:03:47 -0700 (PDT)
Date: Tue, 19 Sep 2000 16:03:46 -0700 (PDT)
From: Indrajanti Sukiman <isukiman@cisco.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Q on DHCPv6 draft (draft-ietf-dhc-dhcpv6-15.txt)
In-Reply-To: <14791.59656.53565.277312@kitab.cisco.com>
Message-ID: <Pine.GSO.4.10.10009191601110.22320-100000@sigma.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


So, given this, I conclude that the check at the agents whether or
not the link-local address is valid or not valid, would be as
trivial as checking the prefix of the link-local address is the well-known
FE80::0 prefix ?

On Tue, 19 Sep 2000, Richard Johnson wrote:

>   Indrajanti Sukiman writes:
>    > My question is, what is the definition of 'a not valid link-local address'?
>    > Or, in other words, how would agents perform this verification ?
>    > As far as I can tell, RFC2462 defines an invalid link-local address as an
>    > address whose valid lifetime has expired. If this is the definition
>    > intended, is there a way e.g. for a DHCPv6 server to know the valid
>    > lifetime of the link-local address of a remote (several hops away) DHCPv6
>    > client ? 
>   
>   I feel sure what's meant is the definition from rfc1884.txt:
>   
>      2.4.8 Local-use IPv6 Unicast Addresses
>   
>      There are two types of local-use unicast addresses defined.  These
>      are Link-Local and Site-Local.  The Link-Local is for use on a single
>      link and the Site-Local is for use in a single site.  Link-Local
>      addresses have the following format:
>   
>       |   10     |
>       |  bits    |        n bits           |       118-n bits           |
>       +----------+-------------------------+----------------------------+
>       |1111111010|           0             |       interface ID         |
>       +----------+-------------------------+----------------------------+
>   
>      Link-Local addresses are designed to be used for addressing on a
>      single link for purposes such as auto-address configuration, neighbor
>      discovery, or when no routers are present.
>   
>      Routers MUST not forward any packets with link-local source
>      addresses.
>   
>   


-- Indrajanti Sukiman




From owner-dhcp-v4@bucknell.edu  Tue Sep 19 20:50:42 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27126
	for <DHC-ARCHIVE@odin.ietf.org>; Tue, 19 Sep 2000 20:50:40 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8K0iFb10263;
	Tue, 19 Sep 2000 20:44:15 -0400 (EDT)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8K0i8b11081
	for <dhcp-v4@bucknell.edu>; Tue, 19 Sep 2000 20:44:08 -0400 (EDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id RAA25996
	for <dhcp-v4@bucknell.edu>; Tue, 19 Sep 2000 17:44:08 -0700 (PDT)
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T118064e11974ec048d59d@mailgate1.apple.com> for <dhcp-v4@bucknell.edu>;
 Tue, 19 Sep 2000 17:44:07 -0700
Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37])
	by scv2.apple.com (8.9.3/8.9.3) with SMTP id RAA22605
	for <dhcp-v4@bucknell.edu>; Tue, 19 Sep 2000 17:44:07 -0700 (PDT)
Message-Id: <200009200044.RAA22605@scv2.apple.com>
Subject: DHCP option codes
Date: Tue, 19 Sep 2000 17:47:07 -0700
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire <cheshire@apple.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Reply-To: cheshire@apple.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

IANA lists all the currently assigned DHCP option codes:

<http://www.isi.edu/in-notes/iana/assignments/bootp-dhcp-parameters>

I was just taking a quick look through the list to see if there are any 
obvious omissions in Mac OS that we ought to fix, but it is hard to tell 
because the list doesn't give the RFCs that define the format and usage 
of each option. Is such a list available anywhere?

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org



From owner-dhcp-v6@bucknell.edu  Tue Sep 19 21:25:45 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27650;
	Tue, 19 Sep 2000 21:25:42 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8K1Jmb11283;
	Tue, 19 Sep 2000 21:19:48 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8K1Jab27413
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 21:19:37 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (sjck-dial-gw5-126.cisco.com [10.19.238.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA05739 for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 21:19:19 -0400 (EDT)
Message-Id: <4.3.1.2.20000919180320.00af8de0@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 19 Sep 2000 18:12:03 -0700
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: Francis's INput at the Design Meeting 
In-Reply-To: <200009192234.AAA22797@givry.rennes.enst-bretagne.fr>
References: <Your message of Mon, 18 Sep 2000 10:38:30 EDT. <63D30D6E10CFD11190A90000F805FE8602BEC16C@lespaul.process.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 12:34 AM 9/20/00 +0200, Francis Dupont wrote:
>  In your previous mail you wrote:
>
>    I'm for keeping the DHCPv6 name.
>
>=> the name doesn't really matter but:
>  - IMHO it is important to understand DHCPv6 is more the statefull version
>    of IPv6 autoconfiguration than the IPv6 version of DHCP, ie. it is
>    supposed to add management to the existing stateless autoconf, not
>    to do things which are exotic (for IPv6) or already done by other
>    tools (like some service discovery).

Can you tell me what you mean by "the stateful version of IPv6
autoconfiguration"?  How does that differ from what the -15 draft
of DHCPv6 does?

- Ralph



From owner-dhcp-v6@bucknell.edu  Tue Sep 19 21:26:28 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27677;
	Tue, 19 Sep 2000 21:26:21 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8K1K7b05818;
	Tue, 19 Sep 2000 21:20:07 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8K1Jdb18912
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 21:19:39 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (sjck-dial-gw5-126.cisco.com [10.19.238.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA05755; Tue, 19 Sep 2000 21:19:22 -0400 (EDT)
Message-Id: <4.3.1.2.20000919181224.00bd4e00@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 19 Sep 2000 18:14:18 -0700
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: Francis's INput at the Design Meeting 
In-Reply-To: <200009192252.AAA22858@givry.rennes.enst-bretagne.fr>
References: <Your message of Mon, 18 Sep 2000 14:41:52 EDT. <200009181841.OAA32274@rotala.raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 12:52 AM 9/20/00 +0200, Francis Dupont wrote:
>  In your previous mail you wrote:
>
>    > I want to state I am now thinking Francis's input at the meeting may
>    > make sense.  Maybe this should not even be called DHCP but Stateful
>    > Address Configuration for IPv6 (SACv6).
>
>    The above title wouldn't seem to be consistent with DHCP being used to
>    send configuration parameters other than addresses (e.g., server
>    addresses, time zone info, etc.).
>
>=> but is this really the job of DHCPv6? As soon as a node gets some
>not too local addresses it can use any service discovery protocol.
>IMHO it is not a good idea to overload DHCPv6 with secondary config
>tasks, ie. DHCPv6 should only manage addresses, DNS and security
>(security because of IPsec usage of destination addresses for SAs,
>DNS because we have no good lightweight/zeroconf DNS tools today).

In theory, I agree with you.  In practice, we've waited a *long* time
for a discovery protocol in the current protocol suite.  Do we
have any confidence that we'll have a discovery protocol specified
and deployed to take ove that role from DHCPv6?

- Ralph



From owner-dhcp-v6@bucknell.edu  Tue Sep 19 21:43:51 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28942;
	Tue, 19 Sep 2000 21:43:49 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8K1dtb30848;
	Tue, 19 Sep 2000 21:39:55 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8K1dfb07166
	for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 21:39:41 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (sjck-dial-gw5-126.cisco.com [10.19.238.127]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA07138 for <dhcp-v6@bucknell.edu>; Tue, 19 Sep 2000 21:39:17 -0400 (EDT)
Message-Id: <4.3.1.2.20000919182913.00af6340@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 19 Sep 2000 18:32:41 -0700
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: <200009191546.LAA0000539338@anw.zk3.dec.com>
References: <Your message of "Tue, 19 Sep 2000 06:39:34 PDT." <4.3.1.2.20000919062909.00ae96e0@mail.bucknell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 11:46 AM 9/19/00 -0400, Jim Bound wrote:
>It makes most sense for the
> >renewal time to be less than the valid lifetimes of all of the IPv6
> >addresses in the IA.
>
>SHould be less than the preferred times.

Agreed...

> >In
> >any event, the server is authoritative about the set of addresses and
> >lifetimes in the IA.
>
>Have to watch for DOS attacks as in IPv6 Stateless where router sends
>zero valid lifetimes with Router Advertisement.

This DOS attack would come from a malicious server?

>Also if a server does
>not return an address which may have valid lifetime left and telnet
>running the connection will be broken as a note.

Yes.

- Ralph



From owner-dhcp-v6@bucknell.edu  Wed Sep 20 12:45:05 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26992;
	Wed, 20 Sep 2000 12:45:05 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8KGfjb29365;
	Wed, 20 Sep 2000 12:41:45 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8KGfYb13969
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 12:41:34 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id E018F2086; Wed, 20 Sep 2000 12:41:18 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id C52F0E99
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 12:41:18 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id MAA0000537482; Wed, 20 Sep 2000 12:40:47 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009201640.MAA0000537482@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Tue, 19 Sep 2000 18:32:41 PDT."
             <4.3.1.2.20000919182913.00af6340@mail.bucknell.edu> 
Date: Wed, 20 Sep 2000 12:40:47 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> >In
> >any event, the server is authoritative about the set of addresses and
> >lifetimes in the IA.
>
>Have to watch for DOS attacks as in IPv6 Stateless where router sends
>zero valid lifetimes with Router Advertisement.

>This DOS attack would come from a malicious server?

I think thats the catch.  But then again my reading of a lot of
discussion is that the IETF community trusts servers more than say other
nodes sending stuff in client server protocol like DHCP.  I just
mentioned it as heads up.  

Thomas you know this stuff pretty well from stateless addrconf can you
comment for us?  thanks (note all I did was implement what thomas
specified in addrconf in this space about only 20 lines of new code).

/jim 



From owner-dhcp-v6@bucknell.edu  Wed Sep 20 13:18:42 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28082;
	Wed, 20 Sep 2000 13:18:42 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8KHFqb12737;
	Wed, 20 Sep 2000 13:15:52 -0400 (EDT)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8KHFdb11716
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 13:15:39 -0400 (EDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e8KHF7u31987
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 19:15:12 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA14854
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 19:15:07 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA27083
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 19:16:58 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200009201716.TAA27083@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Francis's INput at the Design Meeting 
In-reply-to: Your message of Tue, 19 Sep 2000 18:14:18 PDT.
             <4.3.1.2.20000919181224.00bd4e00@mail.bucknell.edu> 
Date: Wed, 20 Sep 2000 19:16:58 +0200
Sender: owner-dhcp-v6@bucknell.edu
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Francis.Dupont@enst-bretagne.fr
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

 In your previous mail you wrote:

   In theory, I agree with you.  In practice, we've waited a *long* time
   for a discovery protocol in the current protocol suite.  Do we
   have any confidence that we'll have a discovery protocol specified
   and deployed to take over that role from DHCPv6?
   
=> we should try to split on a paper the address management part
of DHCPv6 and the general discovery part. I believe two different
protocols won't be really larger than the current multi-purpose one,
and if we look at current issues it is clear most of them belong to only
one of the two parts. Again the situation of IPv4 is different, in IPv6
we already have a form of autoconfig then it is reasonable to use
DHCPv6 only for the discovery part but in this case why to use relays,
...
The real question is what is the faster way from today: throw away
the discovery part in order to get the stateful autoconf ASAP (IPv6
way :-) or the recycle again and again the multi-purpose thing until
we get something useable (DHC/current way :-).

Regards

Francis.Dupont@enst-bretagne.fr

PS: I propose to start with a simple example, for instance NIS server
discovery: if the NIS server is not on-link then we can assume the node
has already a not-too-local address (or it won't be able to reach the
NIS server) then the relay function should be garbage collected.
The information is not releasable (:-) and can be got several time then
a multicast request / unicast (multiple) reply works (remove solicit/
advertisement). The reconfigure function has no more critical too...
This gives a far simpler protocol!



From owner-dhcp-v6@bucknell.edu  Wed Sep 20 13:40:28 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28733;
	Wed, 20 Sep 2000 13:40:28 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8KHdvb18375;
	Wed, 20 Sep 2000 13:39:57 -0400 (EDT)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8KHdlb03618
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 13:39:47 -0400 (EDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e8KHdVu21477
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 19:39:31 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA15123
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 19:39:30 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA27181
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 19:41:22 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200009201741.TAA27181@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Francis's INput at the Design Meeting 
In-reply-to: Your message of Tue, 19 Sep 2000 18:12:03 PDT.
             <4.3.1.2.20000919180320.00af8de0@mail.bucknell.edu> 
Date: Wed, 20 Sep 2000 19:41:22 +0200
Sender: owner-dhcp-v6@bucknell.edu
Reply-To: dhcp-v6@bucknell.edu
X-Sender: Francis.Dupont@enst-bretagne.fr
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

 In your previous mail you wrote:

   Can you tell me what you mean by "the stateful version of IPv6
   autoconfiguration"?

=> according to RFC 2461 introduction:

(what is autoconfiguration)

   This document specifies the steps a host takes in deciding how to
   autoconfigure its interfaces in IP version 6. The autoconfiguration
   process includes creating a link-local address and verifying its
   uniqueness on a link, determining what information should be
   autoconfigured (addresses, other information, or both), and in the
   case of addresses, whether they should be obtained through the
   stateless mechanism, the stateful mechanism, or both.  This document
   defines the process for generating a link-local address, the process
   for generating site-local and global addresses via stateless address
   autoconfiguration, and the Duplicate Address Detection procedure. The
   details of autoconfiguration using the stateful protocol are
   specified elsewhere.

(what is the stateful autoconfiguration)

   In the stateful autoconfiguration model, hosts obtain interface
   addresses and/or configuration information and parameters from a
   server.  Servers maintain a database that keeps track of which
   addresses have been assigned to which hosts. The stateful
   autoconfiguration protocol allows hosts to obtain addresses, other
   configuration information or both from a server.  Stateless and
   stateful autoconfiguration complement each other. For example, a host
   can use stateless autoconfiguration to configure its own addresses,
   but use stateful autoconfiguration to obtain other information.
   Stateful autoconfiguration for IPv6 is the subject of future work
   [DHCPv6].

   How does that differ from what the -15 draft of DHCPv6 does?

=> my concern is about the "other informations". Some are critical
(security, DNS), some can be useful (NIS/NIS+/WINS server), some
are only ridiculous (weather schedule :-).

The current draft tries to be multi-purpose, IMHO this is a bad idea
because this makes DHCPv6 even more complex and not suitable for
a simple discovery mechanism.

Perhaps it is not the time to discuss about this (even if this issue
is a source of the incredible delay of DHCPv6) but I argue (and I'll
continue to argue) that the priority is the address configuration.

We already have the stateless autoconfiguration for years then:
 - we have the proof the discovery part is not (yet) critical
 - we have a lot of constraints on address configuration
   (ie. in some cases DHCPv6 should do the same thing than stateless
    autoconf with the "database that keeps track of which addresses
    have been assigned to which hosts" in (only) addition)

Regards

Francis.Dupont@enst-bretagne.fr



From owner-dhcp-v6@bucknell.edu  Wed Sep 20 20:44:16 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12158;
	Wed, 20 Sep 2000 20:44:16 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8L0f5b29245;
	Wed, 20 Sep 2000 20:41:05 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8L0epb29073
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 20:40:52 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 90D0F3DFA; Wed, 20 Sep 2000 19:40:36 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 27C80266E
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 19:40:36 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id UAA0000592906; Wed, 20 Sep 2000 20:40:04 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009210040.UAA0000592906@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 o n Conference Call Agenda) 
In-reply-to: Your message of "Mon, 18 Sep 2000 18:38:07 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC178@lespaul.process.com> 
Date: Wed, 20 Sep 2000 20:40:03 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>You might also solve them by:
>- Having the client remember the "transaction id" / server source address
>and dropping any reconfigure messages with the same transaction id received
>within some time period (several minutes?). Of course, all subsequent
>retransmitted reconfigure messages MUST use the same "transaction id".
>- Having the client ignore additional multicast reconfigure messages (on the
>same interface) for some time period after receiving one (again, several
>minutes). This method has the added benefit that fake messages can't
>repeatedly trigger reconfigurations except at some reasonable slow rate. Of
>coures, it makes multiple renumbering events take longer (but that they'd
>occur within minutes of each other is rather unlikely anyway).

Yes this would work.  But I think the idea Ralph proposed by server does
multicast once for trigger reconfigure-init and then unicast for those
that did not respond is a simpler solution for now?  A more complex
solution later can be adapted or extended later from what Ralph
proposed pretty easily.  But I do think your idea has much merit.

>I do think the technique in 12.4.2 is somewhat flawed anyway since if one or
>more clients are down, the "expected" number of messages may never be
>returned.

That would need to be fixed I thought we put wording about this
elsewhere but I will check, it might be we only did it for the
reconfigure and not the reconfigure-reply.

>I think a better server strategy is to multicast several Reconfigure
>messages several seconds apart (this presumes that a client hopefully won't
>miss all if it is up and on the network). Then, if any clients fail to
>respond within the alloted time, those clients are sent unicast packets.
>(Perhaps the server can also make a determination of how many clients failed
>to response and if it exceeds some threshold (>50?), it MAY multicast again
>with the same transaction-id).

We did put threshold in there for reconfigure.  But I agree this can
work as you suggest.

Also I think we have to assume one multicast message normally works or
we are not really assuming multicast works.  There should be no reason
to send multiple multicast messages unless there is a network problem.
I suppose if no one responds and then unicasting a few to see if it
works would be a good way to implemement this (not saying put this in
the spec).

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Wed Sep 20 22:51:26 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15341;
	Wed, 20 Sep 2000 22:51:26 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8L2mTb08265;
	Wed, 20 Sep 2000 22:48:29 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8L2mRb08609
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 22:48:27 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA04521
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 19:48:26 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id TAA06713
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 19:48:26 -0700 (PDT)
Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18])
	by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8L2mPa328538
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 19:48:25 -0700 (PDT)
Date: Wed, 20 Sep 2000 19:47:45 -0700 (PDT)
From: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9,  18 on Co nference Call Agenda)
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
In-Reply-To: "Your message with ID" <4.3.1.2.20000915092521.00b92590@mail.bucknell.edu>
Message-ID: <Roam.SIMC.2.0.6.969504465.3648.nordmark@jurassic>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


Catching up on email ... somebody else might have already brought this up.

> I don't think multicast adds efficiency.  It only reduces the number of 
> messages by a constant factor (1/2 at best) and makes reliable 
> communication with clients significantly more difficult.  Security is also 
> a significant issue for multicast.

I agree that it doesn't add efficiency.
But in the case where the DHCP server isn't handing out addresses it might not
retain knowledge of all the clients. Being able to use multicast in that
case to tell all interested clients that there is an updated value to the foo
option, while still requiring O(n) packets, might be useful.

> We can always add multicast later...

Agreed.

   Erik



From owner-dhcp-v6@bucknell.edu  Wed Sep 20 23:12:54 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15591;
	Wed, 20 Sep 2000 23:12:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8L3Cbb24983;
	Wed, 20 Sep 2000 23:12:37 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8L3CWb17203
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 23:12:32 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07956
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 20:12:31 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id UAA09372
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 20:12:31 -0700 (PDT)
Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18])
	by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8L3CPa332877
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 20:12:26 -0700 (PDT)
Date: Wed, 20 Sep 2000 20:11:48 -0700 (PDT)
From: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Co nference Call Agenda) 
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
In-Reply-To: "Your message with ID" <Pine.GSO.4.03.10009162337110.22395-100000@leo>
Message-ID: <Roam.SIMC.2.0.6.969505908.23774.nordmark@jurassic>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


Ralph,


> In any event, multicast is intuitively appealing.  But the devil appears
> to be in the details.  I hope this summary is both concise and precise...

The summary captures the case when the server knows the addresses of 
all the clients it wants to reconfigure.
If the DHCP server doesn't hand out address to a set of clients
it might not want to track the identity of those clients that have only 
received "random" DHCP options/extensions. But the server might still
be interested in being able to use reconfigure to "update" those random
options.

Using multicast in that case has a different set of issues...

Presumably the DHCP server wants to reach all clients so that they all
get the new information (option content) and purge the old information.
But the server doesn't know the whole set of clients that it needs
to receive messages from.

RFC 2894 has a theoretical approach to this type of problem in section 8 for
those interested. But the high-level point is carried in the IESG
note in that RFC:
   This document defines mechanisms for informing a set of routers of
   renumbering operations they are to perform, including a mode of
   operation in environments in which the exact number of routers is
   unknown. Reliably informing all routers when the actual number of
   routers is unknown is a difficult problem. Implementation and
   operational experience will be needed to fully understand the
   applicabilty and scalability aspects of the mechanisms defined in
   this document when the number of routers is unknown.

So while it might be interesting to think about using multicast reconfigure
in this "reconfigure non-address information" case, it is a very hard
problem to do reliably.

  Erik



From owner-dhcp-v6@bucknell.edu  Wed Sep 20 23:37:53 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16253;
	Wed, 20 Sep 2000 23:37:52 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8L3ZTb26472;
	Wed, 20 Sep 2000 23:35:29 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8L3ZJb08612
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 23:35:19 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA11081
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 20:35:18 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id UAA11845
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 20:35:17 -0700 (PDT)
Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18])
	by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8L3ZGa336908
	for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 20:35:16 -0700 (PDT)
Date: Wed, 20 Sep 2000 20:34:38 -0700 (PDT)
From: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Subject: Re: DHCPv6 address model proposal... 
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
In-Reply-To: "Your message with ID" <4.3.1.2.20000919062909.00ae96e0@mail.bucknell.edu>
Message-ID: <Roam.SIMC.2.0.6.969507278.3594.nordmark@jurassic>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


Ralph,

> Let me see if I can successfully summarize the address model we've been 
> discussing:
> 
> [...]
> 
> The renewal time defines the time at which the client must contact the 
> server to get the current state of the IA (call this "renewing" the 
> IA).  The renewal time is independent of the address lifetimes of any of 
> the lifetimes of the IPv6 addresses in the IA.  It makes most sense for the 
> renewal time to be less than the valid lifetimes of all of the IPv6 
> addresses in the IA.

I think the last sentence is actually too much of a simplification.
First of all, for addresses that are fully in use ("preferred" in RFC 2462
terminology i.e. they are neither "deprecated" or "invalid")
you'd really want the renewal time to be less than the shortest preferred
lifetime. This is to ensure that an address doesn't "accidentally" become
deprecated or invalid before the IA is renewed. Thus there has to be
some fudge to allow for the DHCP message exchange necessary to
renew the IA.

But this is not a hard rule. For instance, I expect there will be cases
when a preferred and/or valid lifetime for an address is forced to
zero as part of a renewal. Clearly in  this case the next renewal time should
not be zero.

> When the client renews an IA, the server tells the client about the current 
> set of IPv6 addresses in the IA.  The server may change the set of 
> addresses or the lifetimes of existing addresses during this renewal.  For 
> example, setting a longer lifetime on an address already in the IA is the 
> equivalent of extending the lease on a DHCPv4-managed address.  Leaving an 
> address out of an IA marks it immediately as no longer valid for the 
> client.  Adding a new address to the IA can be used for renumbering.  In 
> any event, the server is authoritative about the set of addresses and 
> lifetimes in the IA.

Hmm, it isn't obvious that we need another way to invalidate an address
(by leaving it out from the IA). Isn't it sufficient to be explicit about
invalidating an address by including it with a zero valid and preferred
lifetime?

   Erik

> - Ralph
> 
> At 09:10 PM 9/15/00 -0700, you wrote:
> 
> > > OK but why is that different than the valid lifetime?  In IPv6 if the
> > > valid timer goes off the connection gets broken.
> >
> >The identity association's renewal time is a construct, based on a
> >process of aggregating all the preferred times (probably) for all the
> >addresses in an identity association.  It exists so that you don't
> >have to renew addresses seperately, and secondarily so that you don't
> >send pointless renewal messages for non-renewable addresses.
> >
> > > I just want to be sure we have not maybe solved this timer problem with
> > > the valid lifetime for an address.
> >
> >I don't think so - the valid timer serves the purpose of making sure
> >that an address stops being used once it becomes invalid, and the
> >renewal timer causes renewal packets to be generated - two different,
> >albeit related, purposes.
> >
> > > But then we could say the renewal time is for the address set in total?
> >
> >Precisamento!   :')
> >
> > > I can live with the client sending back all addresses when it wants to
> > > renew the global address and that will work with the existing IPv6
> > > Address Extension.  It does add extra bytes to the message and I think
> > > we need to at least acknowledge that to a mobile node until we see 156kb
> > > pedestrian throughput for mobile roaming there is a point where we do
> > > need to reduce the bytes we won't see those speeds as I read the Tea
> > > Leaves for Wireless till 2003 as a note.
> > >
> > > I think it fair to ask the WG how they feel about this?
> > >
> > > Do we try to save bytes for mobile nodes in DHCPv6?  I think we should
> > > if its not too complex to implement which is the engineering trade-off.
> >
> >I think if you do the math it's not the clear cut, *particularly* for
> >a mobile node.  Let's say for simplicity (so we have to only talk
> >about one identity association) that you have a mobile node that's not
> >doing mobile IP - it's just changing its address from time to time as
> >it moves around, and doing short-lived transactions on the network.
> >And right now you're sitting in your office with it.   Let's say you
> >get a global address and a site-local address, and the server is
> >giving the global address a renewal time of 24 hours, but the site-
> >local address has a renewal time of a week.   So if you renew
> >addresses together, over a week period, you get this:
> >
> >T+0d00h: DHCPsolicit+DHCPadvertise+DHCPrequest+DHCPreply
> >T+0d12h: DHCPrequest+DHCPreply
> >T+1d00h: DHCPrequest+DHCPreply
> >T+1d12h: DHCPrequest+DHCPreply
> >T+2d00h: DHCPrequest+DHCPreply
> >T+2d12h: DHCPrequest+DHCPreply
> >T+3d00h: DHCPrequest+DHCPreply
> >T+3d12h: DHCPrequest+DHCPreply
> >T+4d00h: DHCPrequest+DHCPreply
> >T+4d12h: DHCPrequest+DHCPreply
> >T+5d00h: DHCPrequest+DHCPreply
> >T+5d12h: DHCPrequest+DHCPreply
> >T+6d00h: DHCPrequest+DHCPreply
> >T+6d12h: DHCPrequest+DHCPreply
> >T+7d00h: DHCPrequest+DHCPreply
> >
> >So you have 1 DHCPsolicit, 1 DHCPadvertise, 15 DHCPrequests and 15
> >DHCPreplies.  So using the current IP Address extension, each
> >DHCPreply contains 64 octets of address extensions, plus a minimal
> >IPv6 header of what, maybe 40 octets, 8 octets of UDP header, and
> >maybe 16 octets of framing, plus maybe another 64 octets of other
> >extensions, plus a 16-octet signature, for a total of 208 octets.  The
> >DHCPrequests, I'm not so sure about, but I'm not convinced that it is
> >going to be usual in a situation like this for them to contain
> >explicit address requests, so let's say they're more like 64 octets of
> >header, 16 octets of extensions and 16 octets of signature, for a
> >total of 96 octets.  The DHCPsolicit is probably roughly the same size
> >as the DHCPrequest - 96 octets.  The DHCPadvertise might be as large
> >as the DHCPreply - 208 octets.  So you have 16 208-octet packets and
> >16 96-octet packets.  So the total traffic size in this scenario is
> >4864 bytes.
> >
> >Now consider your scenario - we have:
> >
> >T+0d00h: DHCPsolicit+DHCPadvertise+DHCPrequest+DHCPreply for both addresses
> >T+0d12h: DHCPrequest+DHCPreply for global
> >T+1d00h: DHCPrequest+DHCPreply for global
> >T+1d12h: DHCPrequest+DHCPreply for global
> >T+2d00h: DHCPrequest+DHCPreply for global
> >T+2d12h: DHCPrequest+DHCPreply for global
> >T+3d00h: DHCPrequest+DHCPreply for global
> >T+3d12h: DHCPrequest+DHCPreply for global
> >T+4d00h: DHCPrequest+DHCPreply for global
> >T+4d12h: DHCPrequest+DHCPreply for global
> >T+5d00h: DHCPrequest+DHCPreply for global
> >T+5d12h: DHCPrequest+DHCPreply for global
> >T+6d00h: DHCPrequest+DHCPreply for global
> >T+6d12h: DHCPrequest+DHCPreply for global
> >T+7d00h: DHCPrequest+DHCPreply for global and site-local
> >
> >So here you have one DHCPsolicit, one DHCPadvertise, 15 DHCPrequests
> >and two DHCPreplies that are the same size as in the previous
> >scenario, for 16x96+3x208.   Plus, you have 13 DHCPreplies that are
> >174 bytes, so this adds up to a total of 4422 bytes.
> >
> >So the actual difference in traffic here is 442 bytes - about 10%.
> >And this is the *worst case scenario*, which you will almost never see
> >in the context of a roaming device in the real world.   It has a
> >site-local and global address with very different lifetimes, which is
> >unlikely in a mobile phone context in the first place.   It didn't
> >move around, so you didn't have to renew because of cell transitions.
> >If we'd been renewing on cell transitions, there's a good chance we
> >would have seen the same number of bytes in both cases, because the
> >renewals would have happened before either lifetime expired.
> >
> >So I think in the real world, with a mobile device like a cell phone,
> >you are going to see no difference in bandwidth consumption.
> >Furthermore, the worst-case scenario I described is susceptible to
> >compression, and we might well want to specify a compression mechanism
> >for low-bandwidth mobile devices anyway.  This would probably burn
> >that 10% down to 1% - an "I didn't move" renewal is going to have a
> >tiny payload in both directions.
> >
> >So I really think that the bandwidth argument isn't a good argument
> >against this scheme.
> >
> >                                _MelloN_
> 



From owner-dhcp-v6@bucknell.edu  Thu Sep 21 03:11:08 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00770;
	Thu, 21 Sep 2000 03:11:08 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8L78Qb03576;
	Thu, 21 Sep 2000 03:08:26 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8L78Fb07549
	for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 03:08:15 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-242.ip.theriver.com [206.97.58.242]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA15474; Tue, 19 Sep 2000 20:32:46 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8L74t309418; Thu, 21 Sep 2000 00:04:59 -0700 (MST)
Message-Id: <200009210704.e8L74t309418@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
cc: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Erik Nordmark <Erik.Nordmark@ENG.SUN.COM> 
   of "Wed, 20 Sep 2000 20:34:38 MST." <Roam.SIMC.2.0.6.969507278.3594.nordmark@jurassic> 
Date: Thu, 21 Sep 2000 00:04:55 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Hmm, it isn't obvious that we need another way to invalidate an address
> (by leaving it out from the IA). Isn't it sufficient to be explicit about
> invalidating an address by including it with a zero valid and preferred
> lifetime?

This requires the server to remember that the client had that address,
so it's actually not a simplification - it makes additional work for
the server, which now has to track the administrative removal of
non-renewable addresses.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Sep 21 16:03:23 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13666;
	Thu, 21 Sep 2000 16:03:23 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8LJxtb04082;
	Thu, 21 Sep 2000 15:59:59 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8LJxcb09282
	for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 15:59:38 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (rtp-dial-1-237.cisco.com [10.83.97.237]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA13218 for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 15:59:18 -0400 (EDT)
Message-Id: <4.3.1.2.20000921153756.00ba2d10@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 21 Sep 2000 15:59:08 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: <Roam.SIMC.2.0.6.969507278.3594.nordmark@jurassic>
References: <"Your message with ID" <4.3.1.2.20000919062909.00ae96e0@mail.bucknell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 08:34 PM 9/20/00 -0700, Erik Nordmark wrote:
>Hmm, it isn't obvious that we need another way to invalidate an address
>(by leaving it out from the IA). Isn't it sufficient to be explicit about
>invalidating an address by including it with a zero valid and preferred
>lifetime?

My thought was that specifying that the server send a complete list of only 
the client's currently valid addresses was actually a simplification - the 
client can simply throw out its old list of addresses and copy down the 
current list from the server.

However, there is a second step - the client has to update the 
configuration of its interfaces with the list of addresses from the 
server.  So, I imagine simply omitting addresses makes the client's job a 
little harder - it has to poke around at each of the interfaces and see if 
any of the addresses on those interfaces were missing from the message and 
must therefore be un-configured.

But, as Ted points out, requiring the server to specifically invalidate 
addresses may make the server implementation more complex - the server will 
have to remember each client's previous list of assigned addresses as well 
as any newly assigned addresses until the client has renewed its IA.

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Sep 21 16:04:17 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13750;
	Thu, 21 Sep 2000 16:04:17 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8LK1qb04132;
	Thu, 21 Sep 2000 16:01:53 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8LK1eb01829
	for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 16:01:41 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (rtp-dial-1-237.cisco.com [10.83.97.237]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA13529 for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 16:01:21 -0400 (EDT)
Message-Id: <4.3.1.2.20000921155922.00ba2500@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 21 Sep 2000 16:03:32 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: <Roam.SIMC.2.0.6.969507278.3594.nordmark@jurassic>
References: <"Your message with ID" <4.3.1.2.20000919062909.00ae96e0@mail.bucknell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 08:34 PM 9/20/00 -0700, Erik Nordmark wrote:
> > It makes most sense for the
> > renewal time to be less than the valid lifetimes of all of the IPv6
> > addresses in the IA.
>
>I think the last sentence is actually too much of a simplification.
>First of all, for addresses that are fully in use ("preferred" in RFC 2462
>terminology i.e. they are neither "deprecated" or "invalid")
>you'd really want the renewal time to be less than the shortest preferred
>lifetime.

Yes, making the renewal time shorter than the shortest preferred lifetime 
would likely be more desirable in most cases.  Without getting overly 
complex or prescriptive, perhaps the text in the spec could say that the 
renewal time MUST be "less than the valid lifetimes of all of the IPv6 
addresses in the IA" for correctness and MAY be "less than the shortest 
preferred lifetime" to be more conservative.

- Ralph



From owner-dhcp-v6@bucknell.edu  Thu Sep 21 16:22:48 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13931;
	Thu, 21 Sep 2000 16:22:47 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8LKMUb28813;
	Thu, 21 Sep 2000 16:22:30 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8LKMHb02533
	for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 16:22:17 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a17.pm3-32.theriver.com [206.102.192.81]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id JAA19071 for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 09:46:48 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8LKIPb03081 for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 13:18:34 -0700 (MST)
Message-Id: <200009212018.e8LKIPb03081@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Ralph Droms <droms@bucknell.edu> 
   of "Thu, 21 Sep 2000 15:59:08 -0400." <4.3.1.2.20000921153756.00ba2d10@mail.bucknell.edu> 
Date: Thu, 21 Sep 2000 13:18:25 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> So, I imagine simply omitting addresses makes the client's job a 
> little harder - it has to poke around at each of the interfaces and see if 
> any of the addresses on those interfaces were missing from the message and 
> must therefore be un-configured.

I doubt a client would poke the interfaces to see what addresses they
have; rather, it would probably remember what addresses were in its
address association.   I think it needs to do this either way.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Sep 21 16:26:50 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14010;
	Thu, 21 Sep 2000 16:26:49 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8LKQWb14596;
	Thu, 21 Sep 2000 16:26:32 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8LKQNb19004
	for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 16:26:24 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a17.pm3-32.theriver.com [206.102.192.81]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id JAA19083 for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 09:50:55 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8LKMeb03144 for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 13:22:40 -0700 (MST)
Message-Id: <200009212022.e8LKMeb03144@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Ralph Droms <droms@bucknell.edu> 
   of "Thu, 21 Sep 2000 16:03:32 -0400." <4.3.1.2.20000921155922.00ba2500@mail.bucknell.edu> 
Date: Thu, 21 Sep 2000 13:22:40 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Yes, making the renewal time shorter than the shortest preferred lifetime 
> would likely be more desirable in most cases.  Without getting overly 
> complex or prescriptive, perhaps the text in the spec could say that the 
> renewal time MUST be "less than the valid lifetimes of all of the IPv6 
> addresses in the IA" for correctness and MAY be "less than the shortest 
> preferred lifetime" to be more conservative.

I think the failover protocol takes advantage of the 50% renewal time
to provide consistent lease times, so it may be good to specify that
the renewal time should be something like half the duration of the
valid lifetime, or 80% of the preferred lifetime, whichever is
shorter.   I'd prefer to just say half the valid lifetime, but
it's possible that the valid lifetime could be more than twice as long
as the preferred lifetime.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Sep 21 17:02:04 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14397;
	Thu, 21 Sep 2000 17:02:03 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8LKxib16892;
	Thu, 21 Sep 2000 16:59:44 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8LKxSb19521
	for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 16:59:28 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (rtp-dial-1-196.cisco.com [10.83.97.196]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA21714 for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 16:59:11 -0400 (EDT)
Message-Id: <4.3.1.2.20000921165538.00ba37e0@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 21 Sep 2000 17:01:16 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: <200009212018.e8LKIPb03081@grosse.bisbee.fugue.com>
References: <Message from Ralph Droms <droms@bucknell.edu>
 <4.3.1.2.20000921153756.00ba2d10@mail.bucknell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 01:18 PM 9/21/00 -0700, you wrote:

> > So, I imagine simply omitting addresses makes the client's job a
> > little harder - it has to poke around at each of the interfaces and see if
> > any of the addresses on those interfaces were missing from the message and
> > must therefore be un-configured.
>
>I doubt a client would poke the interfaces to see what addresses they
>have; rather, it would probably remember what addresses were in its
>address association.   I think it needs to do this either way.

Right.  That's what I get for trying to guess about implementation
strategies...

In any event, if I've got it right, we can assume the client can
do the right thing to change its address configuration to match
the configuration from the server, and the server need not take
responsibility for remembering the client's previous configuration.

- Ralph




From owner-dhcp-v6@bucknell.edu  Thu Sep 21 20:53:09 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16515;
	Thu, 21 Sep 2000 20:53:09 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8M0odb21721;
	Thu, 21 Sep 2000 20:50:39 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8M0oMb31198
	for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 20:50:23 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NKVJ>; Thu, 21 Sep 2000 20:50:07 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC189@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9,  18 
	on Co nference Call Agenda)
Date: Thu, 21 Sep 2000 20:50:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

>> We can always add multicast later...
>
>Agreed.
>
>   Erik

I'm not sure I agree with this. But, it all depends on what you mean by
later. If you're saying not in this revision of the draft, OK. If you're
saying 3 years from now, I think that would be a bad and wrong assumption.
You'll have deployed clients (at least I'm assuming "this time" IPv6 will be
deployed relatively soon - 3 to 4 years ago we were assuming that). Changing
those clients won't come easy because you're assuming we can revise the spec
and they'll all start working - ha!

If no clients support multicast reconfigure, what reason is there for
servers to implement it or use it? If no servers implement or use it, why
build clients that will?

Perhaps I'm being too alarmist here, but I see this as a fairly fundamental
issue and it should be resolved now. I have NO problem in saying that
"clients MUST ignore multicast reconfigure messages unless those message are
authenticated in some manner that is still TBD (perhaps via IPsec, a server
authenticator, or some other means)." This is again somewhat of an issue
since clients will not use these packets until the authentication method is
specified.

- Bernie Volz



From owner-dhcp-v6@bucknell.edu  Thu Sep 21 20:57:10 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16558;
	Thu, 21 Sep 2000 20:57:10 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8M0upb15765;
	Thu, 21 Sep 2000 20:56:51 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8M0uhb03255
	for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 20:56:43 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NKVK>; Thu, 21 Sep 2000 20:56:28 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC18A@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: renewal time
Date: Thu, 21 Sep 2000 20:56:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I think this also means that there is no reason for the client to send the
server the list of addresses it thinks are in the IA. Why waste the bits on
the wire and the server processing time when the server will tell the client
"here's the addresses associated with this IA" in the response anyway.

I've not been following all the discussions to closely the past few days, so
perhaps this was already considered.

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Tuesday, September 19, 2000 9:08 AM
To: DHCPv6 discussion list
Subject: Re: renewal time


I've been thinking of the action associated with renewal as the client 
asking the server "Tell me what addresses are in this IA now and how long I 
can use them".  If the preferred/valid times have changed, it's like a 
lease extension.  If a renumbering event is in progress, the server can 
assign new addresses.  In any event, the server - based on all the 
information the server has about the client - is informing the client of 
the addresses currently in the IA

- Ralph

At 10:42 PM 9/18/00 -0700, Ted Lemon wrote:

> > Correct new lease-times or the Server could not give the client an
> > address back meaning its expired too.  But no new addresses.
>
>Well, but if we're renumbering, the server might well give back a "new
>address", right?  I think the point is that that client isn't asking
>the server to do this - it's asking the server to renew.



From owner-dhcp-v6@bucknell.edu  Thu Sep 21 21:01:18 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16610;
	Thu, 21 Sep 2000 21:01:18 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8M110b16397;
	Thu, 21 Sep 2000 21:01:00 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8M10pb05311
	for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 21:00:51 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NKVQ>; Thu, 21 Sep 2000 21:00:32 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC18B@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: renewal time
Date: Thu, 21 Sep 2000 21:00:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Why not new addresses? If a previous address expired or a reconfigure event
is in progress, why can't there be a new address associated with the IA?

- Bernie Volz

-----Original Message-----
From: Jim Bound [mailto:bound@zk3.dec.com]
Sent: Monday, September 18, 2000 9:14 PM
To: DHCPv6 discussion list
Subject: Re: renewal time



>Jim - when you say "when the client will REQUEST new addresses", do you 
>really mean _new_ addresses, as in _additional_ addresses? I think you mean

>something like "will REQUEST that the server extend the lease-times 
>associated with a client-id": is that correct, or do you really mean "new 
>addresses"?

Correct new lease-times or the Server could not give the client an
address back meaning its expired too.  But no new addresses.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep 21 21:38:33 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17812;
	Thu, 21 Sep 2000 21:38:33 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8M1aDb12877;
	Thu, 21 Sep 2000 21:36:13 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8M1a5b06129
	for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 21:36:06 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a17.pm3-32.theriver.com [206.102.192.81]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id PAA19954 for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 15:00:37 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8M1Vxb18446 for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 18:32:01 -0700 (MST)
Message-Id: <200009220132.e8M1Vxb18446@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: renewal time 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Thu, 21 Sep 2000 21:00:30 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC18B@lespaul.process.com> 
Date: Thu, 21 Sep 2000 18:31:59 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Why not new addresses? If a previous address expired or a reconfigure event
> is in progress, why can't there be a new address associated with the IA?

You are right.   I missed Jim's message about this, I guess.   During
a reconfigure event, the DHCP server can most definitely be expected
to send the client an entirely new IP address for a particular address
association.    Without this, I don't see how the protocol can work.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Sep 21 21:38:38 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17833;
	Thu, 21 Sep 2000 21:38:38 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8M1cLb26982;
	Thu, 21 Sep 2000 21:38:21 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8M1c7b18354
	for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 21:38:07 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a17.pm3-32.theriver.com [206.102.192.81]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id PAA19960 for <dhcp-v6@bucknell.edu>; Wed, 20 Sep 2000 15:02:38 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8M1Y2b18476 for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 18:34:02 -0700 (MST)
Message-Id: <200009220134.e8M1Y2b18476@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: renewal time 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Thu, 21 Sep 2000 20:56:27 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC18A@lespaul.process.com> 
Date: Thu, 21 Sep 2000 18:34:02 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> I think this also means that there is no reason for the client to send the
> server the list of addresses it thinks are in the IA. Why waste the bits on
> the wire and the server processing time when the server will tell the client
> "here's the addresses associated with this IA" in the response anyway.

There is a reason: to preserve address stability.   But it's not a
very good reason, and I think that by default the client probably
shouldn't bother to tell the DHCP server what its old address was.
There's only one catch here: we have to be careful that the client
doesn't get its IA whacked around by two non-cooperating DHCP servers
on the same wire.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Sep 21 22:11:46 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18038;
	Thu, 21 Sep 2000 22:11:46 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8M29Db26291;
	Thu, 21 Sep 2000 22:09:13 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8M292b17749
	for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 22:09:02 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NKWJ>; Thu, 21 Sep 2000 22:08:46 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC18C@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: renewal time
Date: Thu, 21 Sep 2000 22:08:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted:

The multiple server case is an interesting one to consider. I would assume
that the renewals and the like will go to the SAME server and therefore the
client's IA is really specific to that server. But, this does create an
interesting issue for renewals that are multicast (I'm lazy at the moment
and don't recall the exact "renewal" steps in DHCPv6, but I assume we're
allowing multicast at some time if the original server isn't responding).
And, also for any failover protocol (since the servers are different, though
they are cooperating). The failover "lazy update" approach may fail since if
the partner server gets a renewal before the original server updated it with
information, how will the partner know what addresses to give? Urgh!

This really does mean there is a reason for the client to send the list of
addresses on a renewal. This would give "other" servers a hint as to what
the client had and the server can determine "oh, those look like reasonable
addresses to me since they aren't in use (or in use by that client)".

Note also that even if the renewal is sent to the same server, it is always
possible that that server lost stable storage and thus there would be no
information on the server and it would assign new addresses (perhaps not the
same ones) unless the client also sent the addresses with the renewal.

So ... scrap my thought of saving bits and processing. 

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Thursday, September 21, 2000 9:34 PM
To: DHCPv6 discussion list
Subject: Re: renewal time



> I think this also means that there is no reason for the client to send the
> server the list of addresses it thinks are in the IA. Why waste the bits
on
> the wire and the server processing time when the server will tell the
client
> "here's the addresses associated with this IA" in the response anyway.

There is a reason: to preserve address stability.   But it's not a
very good reason, and I think that by default the client probably
shouldn't bother to tell the DHCP server what its old address was.
There's only one catch here: we have to be careful that the client
doesn't get its IA whacked around by two non-cooperating DHCP servers
on the same wire.

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Thu Sep 21 22:11:55 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18060
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 21 Sep 2000 22:11:55 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8M26Pb24982;
	Thu, 21 Sep 2000 22:06:26 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8M26Hb06787
	for <dhcp-v4@bucknell.edu>; Thu, 21 Sep 2000 22:06:17 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1])
	by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id TAA02267;
	Thu, 21 Sep 2000 19:07:57 -0400
Message-Id: <200009212307.TAA02267@hygro.adsl.duke.edu>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP option codes 
In-Reply-To: Message from Stuart Cheshire <cheshire@apple.com> 
   of "Tue, 19 Sep 2000 17:47:07 PDT." <200009200044.RAA22605@scv2.apple.com> 
Date: Thu, 21 Sep 2000 19:07:57 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Reply-To: narten@raleigh.ibm.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Stuart Cheshire <cheshire@apple.com> writes:

> IANA lists all the currently assigned DHCP option codes:

> <http://www.isi.edu/in-notes/iana/assignments/bootp-dhcp-parameters>

> I was just taking a quick look through the list to see if there are any 
> obvious omissions in Mac OS that we ought to fix, but it is hard to tell 
> because the list doesn't give the RFCs that define the format and usage 
> of each option. Is such a list available anywhere?

I've wanted such a list in the past too.  This is something IANA ought
to do. I.e., for all assigned numbers, point to the RFC defining
it. It would probably be a help to IANA (read: it would happen sooner)
if this WG would do this for them, or at least a first cut.

Any takers?

Thomas



From owner-dhcp-v4@bucknell.edu  Thu Sep 21 23:53:03 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20139
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 21 Sep 2000 23:53:02 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8M3n4b16652;
	Thu, 21 Sep 2000 23:49:04 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8M3msb04797
	for <dhcp-v4@bucknell.edu>; Thu, 21 Sep 2000 23:48:54 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (a17.pm3-32.theriver.com [206.102.192.81]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id RAA20262; Wed, 20 Sep 2000 17:13:19 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8M3iVb20056; Thu, 21 Sep 2000 20:44:32 -0700 (MST)
Message-Id: <200009220344.e8M3iVb20056@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP option codes 
In-Reply-To: Message from Thomas Narten <narten@RALEIGH.IBM.COM> 
   of "Thu, 21 Sep 2000 19:07:57 -0400." <200009212307.TAA02267@hygro.adsl.duke.edu> 
Date: Thu, 21 Sep 2000 20:44:31 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Any takers?

You're welcome to start from our list in the ISC DHCP server, since
it's open source.   We don't have every option covered, but we're
pretty close as of 3.0b2pl5.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 22 08:10:44 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11268;
	Fri, 22 Sep 2000 08:10:43 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8MC8Ab09229;
	Fri, 22 Sep 2000 08:08:10 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8MC82b31023
	for <dhcp-v6@bucknell.edu>; Fri, 22 Sep 2000 08:08:02 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1])
	by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id IAA01083
	for <dhcp-v6@bucknell.edu>; Fri, 22 Sep 2000 08:07:35 -0400
Message-Id: <200009221207.IAA01083@hygro.adsl.duke.edu>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Ted Lemon <mellon@nominum.com> 
   of "Fri, 15 Sep 2000 11:22:50 PDT." <200009151822.e8FIMoH01306@grosse.bisbee.fugue.com> 
Date: Fri, 22 Sep 2000 08:07:35 -0400
From: Thomas Narten <narten@RALEIGH.IBM.COM>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted,

Sorry to be so long in following up, but it sounds like we're
basically in sync, except that terminology threw things off. Cool.

One thing in your posting though has me thinking.

> > In the mobile IP scenario, you will likely have *two* global
> > addresses. One for your home address, and a temporary care of
> > address. Both will need to be global in order for arbitrary sites to
> > send packets to them. Note, however, that in this case the client will
> > be interacting with two different DHCP servers in two different
> > contexts. The care-of address comes from the local site that is being
> > visited, the home address comes from the home site. So it's not clear
> > you need to identity associations separately here (though you might
> > want to), since two servers are involved and that is enough to
> > distinguish which addresses one is talking about (i.e., care-of
> > vs. home).

> Right.   So you have two identity associations.

Then later:

> > I hope not. If a client moves to a new link/subnet, it should just
> > request that the DHCP server "give me the set of addresses that I'm
> > supposed to have on the new link I just joined".

> This sounds like the client is making a different request depending on
> it's perception of the status of the link.  Is there any particular
> reason why the client can't just say "please renew this IA" and have
> the server say "okay, because you're on a new link, here are your new
> addresses?"  I.e., the client asks the same question, rather than
> having to be clever and decide which question to ask?   The client
> might be stimulated to ask for an early renewal because it noticed
> that the router advertisements it was seeing had changed, but I don't
> think it needs to explicitly tell the server "hey, I'm on a new
> subnet."

My assumption has been that when a node moves to a new link, it would
ask for addresses using the *same* IA. I.e., the client doesn't want
to know that it is on a new link and therefore needs to use a
different IA when asking for new addresses (but that might be in
conflict with your first point above). However, thinking about it, a
mobile client *will* need to know its on a new link, as all sorts of
things change for it if it moves to a new link (i.e, it needs a new
first-hop router). So having it send a different IA when moving
probably probably isn't a big deal either. But is it really necessary
or desirable?

Thoughts?

Thomas



From owner-dhcp-v6@bucknell.edu  Fri Sep 22 08:17:36 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11423;
	Fri, 22 Sep 2000 08:17:36 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8MCHHb02957;
	Fri, 22 Sep 2000 08:17:17 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8MCH8b00676
	for <dhcp-v6@bucknell.edu>; Fri, 22 Sep 2000 08:17:08 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1])
	by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id IAA01117
	for <dhcp-v6@bucknell.edu>; Fri, 22 Sep 2000 08:16:42 -0400
Message-Id: <200009221216.IAA01117@hygro.adsl.duke.edu>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Ralph Droms <droms@bucknell.edu> 
   of "Tue, 19 Sep 2000 06:39:34 PDT." <4.3.1.2.20000919062909.00ae96e0@mail.bucknell.edu> 
Date: Fri, 22 Sep 2000 08:16:42 -0400
From: Thomas Narten <narten@RALEIGH.IBM.COM>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ralph,

> When the client renews an IA, the server tells the client about the current 
> set of IPv6 addresses in the IA.  The server may change the set of 
> addresses or the lifetimes of existing addresses during this renewal.  For 
> example, setting a longer lifetime on an address already in the IA is the 
> equivalent of extending the lease on a DHCPv4-managed address.  Leaving an 
> address out of an IA marks it immediately as no longer valid for the 
> client.  Adding a new address to the IA can be used for renumbering.  In 
> any event, the server is authoritative about the set of addresses and 
> lifetimes in the IA.

I think that the only way to force a client to "invalidate" or "stop
using" an address is to explicitely tell it that it now has a zero
valid lifetime. Or, one can be silent (omit an address), but that
*does* *not* invalidate the address and cause the client to stop using
it per se. Rather, the client stops using an address when the
addresses' valid lifetime goes to zero. This happens when it times out
through normal expiration (only), but that can be hastened by having
the server send an update saying "the lifetime has now become 0 (or
some other small value)".

My comparison point is stateless addrconf. One doesn't conclude an
address is no longer valid because routers stop advertising it, one
stops using an address when its lifetime expires. If an address is
omitted from an RA, the client probably doesn't even notice this and
doesn't do anything special.  This would seem to simplify a lot of
things.

Note also, that a DHCP server probably *does* want to include all
addresses, including those that will become invalid *very* soon,
because other nodes may be trying to send traffic to those
addresses. If a client has just restarted, it probably won't remember
that it was using an address in the past, but you want it to configure
all of its addresses. If it doesn't, you could run into an odd
situation where a node might have an address (which could be in a
deprecated state), the client reboots, but after reboot, it no longer
has that address configured. But if it hadn't rebooted, it would. This
would seem to be an undesirable situation. And again, it causes no
problem for a client to assign a valid, but deprecated address to its
interfaces. It won't use that address for new communication it
*initiates*, but it will still accept traffic sent to that. This might
happen if the deprecated address was still in the DNS.

Thomas



From owner-dhcp-v6@bucknell.edu  Fri Sep 22 13:46:40 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21623;
	Fri, 22 Sep 2000 13:46:40 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8MHhtb05788;
	Fri, 22 Sep 2000 13:43:55 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8MHhmb28583
	for <dhcp-v6@bucknell.edu>; Fri, 22 Sep 2000 13:43:48 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-229.ip.theriver.com [206.97.58.229]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id HAA23626 for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 07:08:19 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8MHcPw00582 for <dhcp-v6@bucknell.edu>; Fri, 22 Sep 2000 10:38:30 -0700 (MST)
Message-Id: <200009221738.e8MHcPw00582@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Thomas Narten <narten@RALEIGH.IBM.COM> 
   of "Fri, 22 Sep 2000 08:07:35 -0400." <200009221207.IAA01083@hygro.adsl.duke.edu> 
Date: Fri, 22 Sep 2000 10:38:25 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> However, thinking about it, a mobile client *will* need to know its
> on a new link, as all sorts of things change for it if it moves to a
> new link (i.e, it needs a new first-hop router). So having it send a
> different IA when moving probably probably isn't a big deal
> either. But is it really necessary or desirable?

Yes, the highly-mobile client has to notice the link transition.   No,
it doesn't need to use a different IA on each link - indeed, it should
not.   The IA that notices link state changes is for its care-of
address.   The second IA is for its home address, if it's using DHCP
to allocate that.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 22 13:48:24 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21677;
	Fri, 22 Sep 2000 13:48:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8MHm6b05413;
	Fri, 22 Sep 2000 13:48:06 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8MHlwb00241
	for <dhcp-v6@bucknell.edu>; Fri, 22 Sep 2000 13:47:58 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-229.ip.theriver.com [206.97.58.229]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id HAA23656 for <dhcp-v6@bucknell.edu>; Thu, 21 Sep 2000 07:12:29 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8MHhOw00654 for <dhcp-v6@bucknell.edu>; Fri, 22 Sep 2000 10:43:24 -0700 (MST)
Message-Id: <200009221743.e8MHhOw00654@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Thomas Narten <narten@RALEIGH.IBM.COM> 
   of "Fri, 22 Sep 2000 08:16:42 -0400." <200009221216.IAA01117@hygro.adsl.duke.edu> 
Date: Fri, 22 Sep 2000 10:43:24 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Or, one can be silent (omit an address), but that *does* *not*
> invalidate the address and cause the client to stop using it per
> se. Rather, the client stops using an address when the addresses'
> valid lifetime goes to zero.

The way we have talked about this, the client remembers all its
addresses, and the absence of one of these addresses in the response
for an IA indicates that the client should stop using the address
immediately.   We can change to your semantics, but I'm not sure I see
why this would be valuable - in particular, it seems to complicate
things, not make them simpler.   Can you be more explicit in saying
why this is a simplification?   The similarity to stateless addrconf
is a simplification from a protocol perspective, but I'm talking about
implementation here.

> Note also, that a DHCP server probably *does* want to include all
> addresses, including those that will become invalid *very* soon,
> because other nodes may be trying to send traffic to those
> addresses. If a client has just restarted, it probably won't remember
> that it was using an address in the past, but you want it to configure
> all of its addresses.

I think the way we talked about doing this solves this problem - the
client will never receive a DHCPreply that does not list all the valid
addresses for a particular IA.   The absence of an address in the
DHCPreply means that it is no longer valid.   So a client that's
restarted _will_ get all its addresses.

> If it doesn't, you could run into an odd situation where a node
> might have an address (which could be in a deprecated state), the
> client reboots, but after reboot, it no longer has that address
> configured.

So this can't happen.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 22 15:58:47 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25733;
	Fri, 22 Sep 2000 15:58:45 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8MJuAb10305;
	Fri, 22 Sep 2000 15:56:10 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8MJtwb30837
	for <dhcp-v6@bucknell.edu>; Fri, 22 Sep 2000 15:55:58 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA09482 for <dhcp-v6@bucknell.edu>; Fri, 22 Sep 2000 15:55:42 -0400 (EDT)
Message-Id: <4.3.1.2.20000922154355.00ba1220@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 22 Sep 2000 15:57:55 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: <200009221216.IAA01117@hygro.adsl.duke.edu>
References: <Message from Ralph Droms <droms@bucknell.edu>
 <4.3.1.2.20000919062909.00ae96e0@mail.bucknell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 08:16 AM 9/22/00 -0400, Thomas Narten wrote:

>I think that the only way to force a client to "invalidate" or "stop
>using" an address is to explicitely tell it that it now has a zero
>valid lifetime. Or, one can be silent (omit an address), but that
>*does* *not* invalidate the address and cause the client to stop using
>it per se. Rather, the client stops using an address when the
>addresses' valid lifetime goes to zero.

Can't we define explicitly define those semantics within DHCP?  That
is, can't we define a model in which the client and server agree that
the server will send exactly the current state of the IA - the
current list of addresses associated with the IA.  With such a model,
the server would resend every address that continues to be in the IA
and drops those that are no longer in the IA.

>>My comparison point is stateless addrconf. One doesn't
>>conclude an address is no longer valid because routers
>>stop advertising it, one stops using an address when
>>its lifetime expires.

I can understand the desire to be compatible with stateless
autoconf.  But DHCP allows for host-specific configuration
information, rather than information multicast to
many hosts.  So the problem space is a little different,
I think.  I don't see where omitting some of the addresses
sent from a host to a client simplifies anything - that
list of addresses is just the current state for the
client - while explicitly invalidating some addresses
complicates the server logic by requiring that the server
keep track of the client's previous state.

In fact, specifically invalidating addresses complicates
the protocol logic because, as Kim Kinnear pointed out
to me earlier today, DHCP really manages a database of
configuration information that's distributed among the server
and the clients.

If the server must explicitly invalidate
client addresses, it must know what those addresses are.
Easy enough, if the client and server are in sync.  But,
to guarantee correctness in the case that the client
and server are out of sync, the server must know reliably
what addresses the client has in the IA (the server can't
assume that it's version of the IA is the same as the
client's).

So, that synchronization could be accomplished by
requiring that the client send its version of the
IA to the server, and the server could send back the
changes - changing the lifetimes on some addresses,
explicitly invalidating some addresses and adding new
addresses.  That seems more complicated to me than the
server simply sending the client the current, correct,
complete IA.

>Note also, that a DHCP server probably *does* want to include all
>addresses, including those that will become invalid *very* soon,
>because other nodes may be trying to send traffic to those
>addresses.

Agreed...

- Ralph



From owner-dhcp-v6@bucknell.edu  Fri Sep 22 16:04:41 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25811;
	Fri, 22 Sep 2000 16:04:39 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8MK4Jb14077;
	Fri, 22 Sep 2000 16:04:19 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8MK43b13291
	for <dhcp-v6@bucknell.edu>; Fri, 22 Sep 2000 16:04:03 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA10568 for <dhcp-v6@bucknell.edu>; Fri, 22 Sep 2000 16:03:48 -0400 (EDT)
Message-Id: <4.3.1.2.20000922155936.00ae8710@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 22 Sep 2000 16:06:00 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: RE: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 
  18  on Co nference Call Agenda)
In-Reply-To: <63D30D6E10CFD11190A90000F805FE8602BEC189@lespaul.process.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 08:50 PM 9/21/00 -0400, you wrote:
> >> We can always add multicast later...
> >
> >Agreed.
> >
> >   Erik
>
>I'm not sure I agree with this. But, it all depends on what you mean by
>later.

I'm of two minds about "later" - on the one hand, I recognize that,
based on our experience with DHCPv4, we need to get words in the
spec now if we're ever going to deploy multicast reconfigure; on
the other hand, we're already perilously close to slipping
the 9/30 pub date for the next rev of the draft.

- Ralph




From owner-dhcp-v4@bucknell.edu  Fri Sep 22 16:41:30 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26137
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 22 Sep 2000 16:41:30 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8MKbMb16987;
	Fri, 22 Sep 2000 16:37:22 -0400 (EDT)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8MKbBb17005
	for <dhcp-v4@bucknell.edu>; Fri, 22 Sep 2000 16:37:11 -0400 (EDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id NAA02281
	for <dhcp-v4@bucknell.edu>; Fri, 22 Sep 2000 13:37:10 -0700 (PDT)
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <T118064e11974eced9be6f@mailgate1.apple.com> for <dhcp-v4@bucknell.edu>;
 Fri, 22 Sep 2000 13:37:06 -0700
Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37])
	by scv2.apple.com (8.9.3/8.9.3) with SMTP id NAA13081
	for <dhcp-v4@bucknell.edu>; Fri, 22 Sep 2000 13:37:04 -0700 (PDT)
Message-Id: <200009222037.NAA13081@scv2.apple.com>
Subject: DHCP server startup announcement
Date: Fri, 22 Sep 2000 13:40:08 -0700
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire <cheshire@apple.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Reply-To: cheshire@apple.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

When a DHCP client fails to find a DHCP server, it typically keeps 
broadcasting DHCP DISCOVERs at a low rate (e.g. one every five minutes).

Now that so many home users are beginning to use home networks, both 
wired and wireless, we have a lot more casual users of the DHCP protocol. 
A not-too-infrequent scenario is that the user turns on a client machine, 
finds that it isn't working properly, and discovers that this is because 
the gateway/DHCP Server box was not turned on. They then turn on the 
gateway box, and expect the client machine to work, but it could be up to 
five minutes before the next DISCOVER is sent out.

Some Operating Systems today adopt the solution of having special tools, 
command-line programs or Control Panels where the user can take some 
special action to reset the DHCP client, but I think it would be much 
better if it just worked automatically, so that the user didn't have to 
know or care about special tools like this. Computers should "just work". 
In this spirit, I think it would be a good idea if a DHCP server 
broadcast a few "announcement" packets when it starts up, to let waiting 
clients know that a DHCP server is now available.

One thought that occurs to me is that we could borrow from 
draft-ietf-dhc-pv4-reconfigure-01.txt -- the server could broadcast a 
FORCERENEW (perhaps with all zeroes in the chaddr field) effectively 
saying, "To any client that currently has no server-assigned address, and 
would like one, a server is now available for you to send a DISCOVER."

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org



From owner-dhcp-v4@bucknell.edu  Fri Sep 22 17:50:50 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27032
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 22 Sep 2000 17:50:45 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8MLjsb17356;
	Fri, 22 Sep 2000 17:45:54 -0400 (EDT)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8MLjnb17226
	for <dhcp-v4@bucknell.edu>; Fri, 22 Sep 2000 17:45:49 -0400 (EDT)
Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 22 Sep 2000 14:46:17 -0700 (Pacific Daylight Time)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58)
	id <TKLWT1LK>; Fri, 22 Sep 2000 14:46:16 -0700
Message-ID: <5F1EEFAFB3573A46812FE84EF29C9AF52E91D7@red-msg-05.redmond.corp.microsoft.com>
From: Matthew Williamson <mattwi@microsoft.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Domain Suffix Search List
Date: Fri, 22 Sep 2000 14:45:06 -0700
X-Mailer: Internet Mail Service (5.5.2651.58)
Reply-To: mattwi@microsoft.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hello All,

I have been wondering as to the current state of the option to add a Domain
Suffix Search list to the list of possible DHCP options.

I've heard that this has been in the works before, but haven't seen anything
on this for quite some time.

If there's something we can do to help out with this, please let me know.

Matthew Williamson
Program Manager - DHCP Server
Microsoft Corporation



From owner-dhcp-v6@bucknell.edu  Fri Sep 22 23:49:17 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04979;
	Fri, 22 Sep 2000 23:49:17 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8N3jPb07052;
	Fri, 22 Sep 2000 23:45:25 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8N3jKb10829
	for <dhcp-v6@bucknell.edu>; Fri, 22 Sep 2000 23:45:20 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id 8B41C2287; Fri, 22 Sep 2000 22:45:04 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 19A7520E1
	for <dhcp-v6@bucknell.edu>; Fri, 22 Sep 2000 22:45:04 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id XAA0000836629; Fri, 22 Sep 2000 23:44:45 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009230344.XAA0000836629@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: bound@ZK3.DEC.COM
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Fri, 22 Sep 2000 15:57:55 EDT."
             <4.3.1.2.20000922154355.00ba1220@mail.bucknell.edu> 
Date: Fri, 22 Sep 2000 23:44:44 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ralph,

The current dhcpv6 does try to emulate what the router does in stateless
addrconf but with the obvious need to support as you say all the
knowledge the server must now keep by definition which the router does
not try to in neighbor discovery.  The router of course is truly
stateless.  The complexity to do this is to mirror the addrconf paradigm
as close as possible.  Thus a paradigm shift from DHCPv4.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Sat Sep 23 00:33:13 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05401;
	Sat, 23 Sep 2000 00:33:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8N4TYb27677;
	Sat, 23 Sep 2000 00:29:34 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8N4TRb26595
	for <dhcp-v6@bucknell.edu>; Sat, 23 Sep 2000 00:29:27 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-229.ip.theriver.com [206.97.58.229]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id RAA25294; Thu, 21 Sep 2000 17:53:56 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8N4O4w11550; Fri, 22 Sep 2000 21:24:05 -0700 (MST)
Message-Id: <200009230424.e8N4O4w11550@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
cc: bound@ZK3.DEC.COM
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Fri, 22 Sep 2000 23:44:44 -0400." <200009230344.XAA0000836629@anw.zk3.dec.com> 
Date: Fri, 22 Sep 2000 21:24:04 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> The complexity to do this is to mirror the addrconf paradigm
> as close as possible.  Thus a paradigm shift from DHCPv4.

Mirroring the behaviour of one system designed for one purpose in
another system designed for a different purpose is not a paradigm
shift.  It is just a design decision that you maked based on a
cost/benefit analysis.  We've talked about the issues involved quite a
bit, although not from this particular perspective.  I don't think
trying to artificially impose similarities between stateless and
stateful autoconfig is a good idea.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Sat Sep 23 01:08:05 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06064;
	Sat, 23 Sep 2000 01:08:05 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8N546b02712;
	Sat, 23 Sep 2000 01:04:06 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8N53sb14767
	for <dhcp-v6@bucknell.edu>; Sat, 23 Sep 2000 01:03:54 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id D4B748C5; Sat, 23 Sep 2000 01:03:38 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP
	id 2368C2987; Sat, 23 Sep 2000 01:03:38 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id BAA0000843899; Sat, 23 Sep 2000 01:02:48 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009230502.BAA0000843899@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: dhcp-v6@bucknell.edu, bound@ZK3.DEC.COM, bound@ZK3.DEC.COM
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Fri, 22 Sep 2000 21:24:04 PDT."
             <200009230424.e8N4O4w11550@grosse.bisbee.fugue.com> 
Date: Sat, 23 Sep 2000 01:02:43 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>> The complexity to do this is to mirror the addrconf paradigm
>> as close as possible.  Thus a paradigm shift from DHCPv4.

>Mirroring the behaviour of one system designed for one purpose in
>another system designed for a different purpose is not a paradigm
>shift.  It is just a design decision that you maked based on a
>cost/benefit analysis.  We've talked about the issues involved quite a
>bit, although not from this particular perspective.  I don't think
>trying to artificially impose similarities between stateless and
>stateful autoconfig is a good idea.

The end result if implemented would be a paradigm shift completely.  It is
what would happen after the design decision was executed.  Also it was
not artificial but real by using the parts in IPv6 that made it
possible.  But, regardless we don't agree on your last point and I did
not send this to debate it but rather as additional data for the
conversation of stateful vs stateless.

Also as I listen to Francis's input we should have taken the design a
step further and did a stateful discovery protocol, then stateful address
protocol, and then one for config parameters that are not addresses. 
And completely left the entire DHCP paradigm maybe.

But what we have to do now is I think just permit the server to not
return the address.  

But if the client still has time left to use that address the connection
should not be broken as I believe that stateless addrconf as a spec is
the architecture for that decision not ours.  So if a server wants to
stop a client from using an address that still has time left they should
have to send the address back to the client with a reduced lease to end
the connection and use of that address.  Or just let it time out and it
will not get it back and in this new model it can't request a new
address really but must look for another one that may exist from
previous REPLY.

regards,
/jim 



From owner-dhcp-v6@bucknell.edu  Sat Sep 23 01:46:29 2000
Received: from mail.bucknell.edu ([134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10085;
	Sat, 23 Sep 2000 01:46:29 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8N5gnb01107;
	Sat, 23 Sep 2000 01:42:49 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8N5gdb29656
	for <dhcp-v6@bucknell.edu>; Sat, 23 Sep 2000 01:42:39 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-229.ip.theriver.com [206.97.58.229]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id TAA25435; Thu, 21 Sep 2000 19:07:09 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8N5b3w12415; Fri, 22 Sep 2000 22:37:03 -0700 (MST)
Message-Id: <200009230537.e8N5b3w12415@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
cc: dhcp-v6@bucknell.edu
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Jim Bound <bound@zk3.dec.com> 
   of "Sat, 23 Sep 2000 01:02:43 -0400." <200009230502.BAA0000843899@anw.zk3.dec.com> 
Date: Fri, 22 Sep 2000 22:37:03 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> But if the client still has time left to use that address the connection
> should not be broken as I believe that stateless addrconf as a spec is
> the architecture for that decision not ours.  So if a server wants to
> stop a client from using an address that still has time left they should
> have to send the address back to the client with a reduced lease to end
> the connection and use of that address.

It seems like what you are disputing is how the server notifies the
client that an address must be dropped, not whether it can.   Am I
right?   So what does this have to do with stateless address
configuration?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Sun Sep 24 08:03:03 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08157;
	Sun, 24 Sep 2000 08:03:03 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8OC0Hb24069;
	Sun, 24 Sep 2000 08:00:17 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8OC02b18183
	for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 08:00:02 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NMGH>; Sun, 24 Sep 2000 07:59:47 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC194@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Sun, 24 Sep 2000 07:59:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

>So, that synchronization could be accomplished by
>requiring that the client send its version of the
>IA to the server, and the server could send back the
>changes - changing the lifetimes on some addresses,
>explicitly invalidating some addresses and adding new
>addresses.  That seems more complicated to me than the
>server simply sending the client the current, correct,
>complete IA.

I believe, though perhaps more complicated, that this will be required. Now,
it is a matter of discussion whether an "invalid" address in the client's
renewal is explicitly or implicitly invalidated - the server could send back
lifetimes of 0 or it could simply not return that address (the client then
would either invalidate the missing address or would keep using it until the
previously received lifetime expires). I think that we should allow the two
different behavoirs:
1. Server explicitly responds with 0 lifetimes to force the client to
invalidate the address immediately.
2. Server doesn't respond with the address (perhaps because it is no longer
or never was authoritative for that address) and the client is allowed to
continue using that address until the lifetime expires (since that's what
the original 'lease' give it in terms of 'rights'). Note that in this case,
the client MUST continue to send this address in any future renewals UNTIL
it has stopped using the address (lifetime expires).

I actually believe that #2 will have some value in mobility or similar
environments.

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]
Sent: Friday, September 22, 2000 3:58 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...


At 08:16 AM 9/22/00 -0400, Thomas Narten wrote:

>I think that the only way to force a client to "invalidate" or "stop
>using" an address is to explicitely tell it that it now has a zero
>valid lifetime. Or, one can be silent (omit an address), but that
>*does* *not* invalidate the address and cause the client to stop using
>it per se. Rather, the client stops using an address when the
>addresses' valid lifetime goes to zero.

Can't we define explicitly define those semantics within DHCP?  That
is, can't we define a model in which the client and server agree that
the server will send exactly the current state of the IA - the
current list of addresses associated with the IA.  With such a model,
the server would resend every address that continues to be in the IA
and drops those that are no longer in the IA.

>>My comparison point is stateless addrconf. One doesn't
>>conclude an address is no longer valid because routers
>>stop advertising it, one stops using an address when
>>its lifetime expires.

I can understand the desire to be compatible with stateless
autoconf.  But DHCP allows for host-specific configuration
information, rather than information multicast to
many hosts.  So the problem space is a little different,
I think.  I don't see where omitting some of the addresses
sent from a host to a client simplifies anything - that
list of addresses is just the current state for the
client - while explicitly invalidating some addresses
complicates the server logic by requiring that the server
keep track of the client's previous state.

In fact, specifically invalidating addresses complicates
the protocol logic because, as Kim Kinnear pointed out
to me earlier today, DHCP really manages a database of
configuration information that's distributed among the server
and the clients.

If the server must explicitly invalidate
client addresses, it must know what those addresses are.
Easy enough, if the client and server are in sync.  But,
to guarantee correctness in the case that the client
and server are out of sync, the server must know reliably
what addresses the client has in the IA (the server can't
assume that it's version of the IA is the same as the
client's).

So, that synchronization could be accomplished by
requiring that the client send its version of the
IA to the server, and the server could send back the
changes - changing the lifetimes on some addresses,
explicitly invalidating some addresses and adding new
addresses.  That seems more complicated to me than the
server simply sending the client the current, correct,
complete IA.

>Note also, that a DHCP server probably *does* want to include all
>addresses, including those that will become invalid *very* soon,
>because other nodes may be trying to send traffic to those
>addresses.

Agreed...

- Ralph



From owner-dhcp-v6@bucknell.edu  Sun Sep 24 14:27:48 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09846;
	Sun, 24 Sep 2000 14:27:47 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8OIOob01334;
	Sun, 24 Sep 2000 14:24:50 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8OIOYb00069
	for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 14:24:35 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-77.ip.theriver.com [206.97.58.77]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id HAA02439 for <dhcp-v6@bucknell.edu>; Sat, 23 Sep 2000 07:49:04 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8OIOIe02576 for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 11:24:19 -0700 (MST)
Message-Id: <200009241824.e8OIOIe02576@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Sun, 24 Sep 2000 07:59:44 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC194@lespaul.process.com> 
Date: Sun, 24 Sep 2000 11:24:18 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> >So, that synchronization could be accomplished by requiring that
> >the client send its version of the IA to the server, and the server
> >could send back the changes

> I believe, though perhaps more complicated, that this will be required.

Why do you believe this?   I don't think this is required at all, and
it does create a great deal of complexity, as well as making client
packets a lot fatter.   Can you explain why you believe that this is
necessary?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Sun Sep 24 14:54:14 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09994;
	Sun, 24 Sep 2000 14:54:14 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8OIrwb13662;
	Sun, 24 Sep 2000 14:53:58 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8OIrqb10540
	for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 14:53:52 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NMH4>; Sun, 24 Sep 2000 14:53:36 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC195@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Sun, 24 Sep 2000 14:53:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

>> >So, that synchronization could be accomplished by requiring that
>> >the client send its version of the IA to the server, and the server
>> >could send back the changes
>
>> I believe, though perhaps more complicated, that this will be required.
>
>Why do you believe this?   I don't think this is required at all, and
>it does create a great deal of complexity, as well as making client
>packets a lot fatter.   Can you explain why you believe that this is
>necessary?
>
>			       _MelloN_

Ted:

I explained the need for this a few days ago ... you were the one that
suggested it! It has to do with the renewal time discussion - see the emails
below.

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Bernie Volz 
Sent: Thursday, September 21, 2000 10:09 PM
To: 'dhcp-v6@bucknell.edu'
Subject: RE: renewal time


Ted:

The multiple server case is an interesting one to consider. I would assume
that the renewals and the like will go to the SAME server and therefore the
client's IA is really specific to that server. But, this does create an
interesting issue for renewals that are multicast (I'm lazy at the moment
and don't recall the exact "renewal" steps in DHCPv6, but I assume we're
allowing multicast at some time if the original server isn't responding).
And, also for any failover protocol (since the servers are different, though
they are cooperating). The failover "lazy update" approach may fail since if
the partner server gets a renewal before the original server updated it with
information, how will the partner know what addresses to give? Urgh!

This really does mean there is a reason for the client to send the list of
addresses on a renewal. This would give "other" servers a hint as to what
the client had and the server can determine "oh, those look like reasonable
addresses to me since they aren't in use (or in use by that client)".

Note also that even if the renewal is sent to the same server, it is always
possible that that server lost stable storage and thus there would be no
information on the server and it would assign new addresses (perhaps not the
same ones) unless the client also sent the addresses with the renewal.

So ... scrap my thought of saving bits and processing. 

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Thursday, September 21, 2000 9:34 PM
To: DHCPv6 discussion list
Subject: Re: renewal time



> I think this also means that there is no reason for the client to send the
> server the list of addresses it thinks are in the IA. Why waste the bits
on
> the wire and the server processing time when the server will tell the
client
> "here's the addresses associated with this IA" in the response anyway.

There is a reason: to preserve address stability.   But it's not a
very good reason, and I think that by default the client probably
shouldn't bother to tell the DHCP server what its old address was.
There's only one catch here: we have to be careful that the client
doesn't get its IA whacked around by two non-cooperating DHCP servers
on the same wire.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Sun Sep 24 15:26:44 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10163;
	Sun, 24 Sep 2000 15:26:43 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8OJOPb00555;
	Sun, 24 Sep 2000 15:24:26 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8OJONb01245
	for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 15:24:23 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-77.ip.theriver.com [206.97.58.77]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id IAA02589 for <dhcp-v6@bucknell.edu>; Sat, 23 Sep 2000 08:48:52 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8OJO3e03316 for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 12:24:03 -0700 (MST)
Message-Id: <200009241924.e8OJO3e03316@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Sun, 24 Sep 2000 14:53:35 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC195@lespaul.process.com> 
Date: Sun, 24 Sep 2000 12:24:03 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> I explained the need for this a few days ago ... you were the one that
> suggested it! It has to do with the renewal time discussion - see the emails
> below.

No, I said that it might be *useful* on some occasions for the client
to send the address in as a hint to the server.  I do not believe that
it is *generally* useful.   I certainly don't think the protocol
should be based on the client always doing this.

I also brought up the problem that a client might lose all its
addresses because it connected with a different server on the same
wire.   Having the client say what addresses it has doesn't solve this
problem, though.

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Sun Sep 24 22:35:21 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13959
	for <DHC-ARCHIVE@odin.ietf.org>; Sun, 24 Sep 2000 22:35:20 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8P2Tsb14732;
	Sun, 24 Sep 2000 22:29:54 -0400 (EDT)
Received: from rmx308-mta.mail.com (rmx308-mta.mail.com [165.251.48.43])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8P2Tmb14573
	for <dhcp-v4@bucknell.edu>; Sun, 24 Sep 2000 22:29:48 -0400 (EDT)
Received: from web586-ec.mail.com (web586-ec.mail.com [165.251.32.78])
	by rmx308-mta.mail.com (8.9.3/8.9.3) with SMTP id WAA02565
	for <dhcp-v4@bucknell.edu>; Sun, 24 Sep 2000 22:29:47 -0400 (EDT)
Message-ID: <381538711.969848987522.JavaMail.root@web586-ec.mail.com>
Date: Sun, 24 Sep 2000 22:29:46 -0400 (EDT)
From: Rajeev Chawla <rajeevchawla@email.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: DHCP over nonbroadcast media
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: mail.com
X-Originating-IP: 216.67.2.126
Reply-To: rajeevchawla@email.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

Hi,

I read that the use of DHCP over nonbroadcast media has been proposed, but I
could not find any internet drafts anywhere.  Can someone please point me to
them.

Also can someone tell me where I can find more information about
"self-discovering" networks proposed by Walt Lazear.

Thanks in advance,

Rajeev


-----------------------------------------------
FREE! The World's Best Email Address @email.com
Reserve your name now at http://www.email.com



From owner-dhcp-v6@bucknell.edu  Sun Sep 24 23:28:46 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14190;
	Sun, 24 Sep 2000 23:28:46 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8P3QGb10493;
	Sun, 24 Sep 2000 23:26:16 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8P3Q7b28637
	for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 23:26:07 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 8D592717B; Sun, 24 Sep 2000 23:25:52 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP
	id 3B5697173; Sun, 24 Sep 2000 23:25:52 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id XAA0000627106; Sun, 24 Sep 2000 23:24:40 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009250324.XAA0000627106@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: dhcp-v6@bucknell.edu
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Fri, 22 Sep 2000 22:37:03 PDT."
             <200009230537.e8N5b3w12415@grosse.bisbee.fugue.com> 
Date: Sun, 24 Sep 2000 23:24:40 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>> But if the client still has time left to use that address the connection
>> should not be broken as I believe that stateless addrconf as a spec is
>> the architecture for that decision not ours.  So if a server wants to
>> stop a client from using an address that still has time left they should
>> have to send the address back to the client with a reduced lease to end
>> the connection and use of that address.

>It seems like what you are disputing is how the server notifies the
>client that an address must be dropped, not whether it can.   Am I
>right?   So what does this have to do with stateless address
>configuration?

Yes the issue is how.

In the existing IPv6 implementations and deployed IPv6 nodes when a
router provides a node with an address with valid and preferred
lifetimes, and then later sends another router advertisement but not
with prefixes previously sent.

Example Router Advertisement #1 (to be used for autoconfgiguration so
the A bit is set)

Prefix 44fe::/64
   Valid Lifetime 5 days
   Preferred Lifetime 4 days and 1400 hours 

Then Router Advertisement #2 is

Prefix 33fe::/64
   Valid Lifetime 5 hours
   Preferred Lifetime 3 hours 

When the second Router Advertisement #2 happens it has no affect to the
first Router Advertisement.  The only way the Router can stop use of the
44fe prefix is as follows:

Router Advertisement #3

Prefix 4ffe::/64
   Valid Lifetime 2 hours
   Preferred Lifetime 2 hours

IPv6 does not permit a router to send a zero lifetime unless IPsec is
being used with neighbor discovery.

So what I am stating is that if the server sends back a Reply and there
is no address in the packet which the client is still using and received
from DHCPv6 the client cannot break the IPv6 connections using that address 
per the rules defined in stateless addrconf.  The reason is that addrconf
has defined a behavior and we cannot break that with a stateful
protocol.  Basically stateless holds some rule over the architecture for
implementation.

regards,
/jim 



From owner-dhcp-v6@bucknell.edu  Sun Sep 24 23:57:55 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14748;
	Sun, 24 Sep 2000 23:57:55 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8P3vJb06954;
	Sun, 24 Sep 2000 23:57:19 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8P3vDb31864
	for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 23:57:13 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 6D32331BE; Sun, 24 Sep 2000 23:56:54 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id 57BE03203
	for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 23:56:54 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id XAA0000631053; Sun, 24 Sep 2000 23:56:18 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009250356.XAA0000631053@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Sun, 24 Sep 2000 23:24:40 EDT."
             <200009250324.XAA0000627106@anw.zk3.dec.com> 
Date: Sun, 24 Sep 2000 23:56:18 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

So the renewal time will always be less than the preferred lifetime for
a single address?

And the renewal time will always be less than the smallest preferred
lifetime for an address set provided by the server?

regards,
/jim



From owner-dhcp-v4@bucknell.edu  Mon Sep 25 02:56:11 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28063
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 25 Sep 2000 02:56:11 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8P6otb30374;
	Mon, 25 Sep 2000 02:50:55 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8P6orb23538
	for <dhcp-v4@bucknell.edu>; Mon, 25 Sep 2000 02:50:53 -0400 (EDT)
Received: from efra05-home.Germany.Sun.COM ([129.157.43.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA21767;
	Sun, 24 Sep 2000 23:50:50 -0700 (PDT)
Received: from vayne (muc-isdn-1 [129.157.164.101])
	by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id IAA13079;
	Mon, 25 Sep 2000 08:50:48 +0200 (MET DST)
Date: Mon, 25 Sep 2000 09:00:29 +0200 (MET DST)
From: Erik Guttman <Erik.Guttman@germany.sun.com>
Reply-To: Erik Guttman <Erik.Guttman@germany.sun.com>
Subject: Re: DHCP server startup announcement
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
In-Reply-To: "Your message with ID" <200009222037.NAA13081@scv2.apple.com>
Message-ID: <Roam.SIMC.2.0.6.969865229.1726.erikg@sun-ffm.germany>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


Stuart Cheshire wrote:
> When a DHCP client fails to find a DHCP server, it typically keeps 
> broadcasting DHCP DISCOVERs at a low rate (e.g. one every five minutes).
...
> One thought that occurs to me is that we could borrow from 
> draft-ietf-dhc-pv4-reconfigure-01.txt -- the server could broadcast a 
> FORCERENEW (perhaps with all zeroes in the chaddr field) effectively 
> saying, "To any client that currently has no server-assigned address, and 
> would like one, a server is now available for you to send a DISCOVER."

I fully support this direction.  This will make it much easier for
auto configured clients to discover DHCP servers.  One of the problems
with the 'polling model' is that devices will discover the DHCP server
at different times.  During this 'transition' phase, some devices could
potentially be unable to communicate.  This could be avoided by having
devices discover the DHCP server through an announcement and transition
en masse.  Considering that - there should be some randomizing interval
so that hosts that receive the FORCERENEW don't all try to hit the DHCP
server at once :-)

Erik



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 06:50:04 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29321;
	Mon, 25 Sep 2000 06:50:04 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PAlXb17130;
	Mon, 25 Sep 2000 06:47:33 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PAlUb10369
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 06:47:30 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NMMA>; Mon, 25 Sep 2000 06:47:15 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC196@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Mon, 25 Sep 2000 06:47:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

A new client or an existing client can always lose all of its addresses. If
the client DOESN'T know its addresses, it can't supply them. However, if a
client does have a record of addresses, it should supply them as a "hint" to
the server.

I believe that it is generally useful and should be required of the client
if it has any addresses for which the lifetimes have not "expired".

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Sunday, September 24, 2000 3:24 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...



> I explained the need for this a few days ago ... you were the one that
> suggested it! It has to do with the renewal time discussion - see the
emails
> below.

No, I said that it might be *useful* on some occasions for the client
to send the address in as a hint to the server.  I do not believe that
it is *generally* useful.   I certainly don't think the protocol
should be based on the client always doing this.

I also brought up the problem that a client might lose all its
addresses because it connected with a different server on the same
wire.   Having the client say what addresses it has doesn't solve this
problem, though.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 06:51:35 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29463;
	Mon, 25 Sep 2000 06:51:35 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PApKb22728;
	Mon, 25 Sep 2000 06:51:20 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PAp6b20110
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 06:51:06 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NMMB>; Mon, 25 Sep 2000 06:50:51 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC197@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Mon, 25 Sep 2000 06:50:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Jim ... I think you have it. If the server's reply does not include an
address that the client previously had for that IA, the client should follow
the normal rules and continue using that address until the lifetimes expire.

This is just like stateless addrconf.

- Bernie Volz

-----Original Message-----
From: Jim Bound [mailto:bound@zk3.dec.com]
Sent: Sunday, September 24, 2000 11:25 PM
To: DHCPv6 discussion list
Cc: dhcp-v6@bucknell.edu
Subject: Re: DHCPv6 address model proposal...



>> But if the client still has time left to use that address the connection
>> should not be broken as I believe that stateless addrconf as a spec is
>> the architecture for that decision not ours.  So if a server wants to
>> stop a client from using an address that still has time left they should
>> have to send the address back to the client with a reduced lease to end
>> the connection and use of that address.

>It seems like what you are disputing is how the server notifies the
>client that an address must be dropped, not whether it can.   Am I
>right?   So what does this have to do with stateless address
>configuration?

Yes the issue is how.

In the existing IPv6 implementations and deployed IPv6 nodes when a
router provides a node with an address with valid and preferred
lifetimes, and then later sends another router advertisement but not
with prefixes previously sent.

Example Router Advertisement #1 (to be used for autoconfgiguration so
the A bit is set)

Prefix 44fe::/64
   Valid Lifetime 5 days
   Preferred Lifetime 4 days and 1400 hours 

Then Router Advertisement #2 is

Prefix 33fe::/64
   Valid Lifetime 5 hours
   Preferred Lifetime 3 hours 

When the second Router Advertisement #2 happens it has no affect to the
first Router Advertisement.  The only way the Router can stop use of the
44fe prefix is as follows:

Router Advertisement #3

Prefix 4ffe::/64
   Valid Lifetime 2 hours
   Preferred Lifetime 2 hours

IPv6 does not permit a router to send a zero lifetime unless IPsec is
being used with neighbor discovery.

So what I am stating is that if the server sends back a Reply and there
is no address in the packet which the client is still using and received
from DHCPv6 the client cannot break the IPv6 connections using that address 
per the rules defined in stateless addrconf.  The reason is that addrconf
has defined a behavior and we cannot break that with a stateful
protocol.  Basically stateless holds some rule over the architecture for
implementation.

regards,
/jim 



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 07:00:43 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29544;
	Mon, 25 Sep 2000 07:00:43 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PB09b30129;
	Mon, 25 Sep 2000 07:00:09 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PB04b21297
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 07:00:04 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NMM1>; Mon, 25 Sep 2000 06:59:52 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC198@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Mon, 25 Sep 2000 06:59:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Yes, as I understand it that is what was being proposed.

There may be cases where the renewal time could be larger than the preferred
lifetime, for example if the server isn't going to be renewing that address.
Perhaps the preferred is the same as the valid and is 2 hours (similar to
your stateless router advertisement examples where the address is going
away), and hence the renewal time could be longer than 2 hours. 

We do need to be careful to avoid a situation when an address is going away.
Suppose it is going away in 2 hours. If a new client gets a lease, if the
renewal time is set to 2 hours, it will renew in 1 hour. At that 1 hour
time, it will get a preferred of 1 hour. Client will renew in 30 minutes, it
gets renewal time of 30 minutes. Renews in 15 ...

So, we might state the renewal time as "In general, the renewal time of an
IA will be less than the smallest preferred lifetime of the non-depreciated
addresses in the IA." (Or something like that.)

- Bernie Volz

-----Original Message-----
From: Jim Bound [mailto:bound@zk3.dec.com]
Sent: Sunday, September 24, 2000 11:56 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...


So the renewal time will always be less than the preferred lifetime for
a single address?

And the renewal time will always be less than the smallest preferred
lifetime for an address set provided by the server?

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 07:39:33 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00174;
	Mon, 25 Sep 2000 07:39:32 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PBafb18103;
	Mon, 25 Sep 2000 07:36:43 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PBa5b07817
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 07:36:05 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1])
	by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id HAA11579
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 07:35:28 -0400
Message-Id: <200009251135.HAA11579@hygro.adsl.duke.edu>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Ted Lemon <mellon@nominum.com> 
   of "Fri, 22 Sep 2000 10:43:24 PDT." <200009221743.e8MHhOw00654@grosse.bisbee.fugue.com> 
Date: Mon, 25 Sep 2000 07:35:28 -0400
From: Thomas Narten <narten@RALEIGH.IBM.COM>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted Lemon <mellon@nominum.com> writes:

> > Or, one can be silent (omit an address), but that *does* *not*
> > invalidate the address and cause the client to stop using it per
> > se. Rather, the client stops using an address when the addresses'
> > valid lifetime goes to zero.

> The way we have talked about this, the client remembers all its
> addresses, and the absence of one of these addresses in the response
> for an IA indicates that the client should stop using the address
> immediately.

One reason why the above semantics are perhaps not ideal concerns when
both stateless addrconf *and* DHCPv6 happen to be sending out
information about the same address. Sure, one can argue that this is a
misconfiguration, but it will happen sometimes, and the protocol needs
to define the correct behavior in that case. The addrconf spec says
that in all cases, whenever a node gets "new" information (either from
stateless addrconf or DHCP) that new information becomes definitive
and supercedes any information about that address received in the
past. Thus, a "new" DHCP update always overrides a previous stateless
addrconf advertisement and vice versa.  This choice was made to keep
things simple, as it removes corner cases having to do when deciding
whether to believe stateless over DHCP or vice versa.

For example, if an address is being advertised by both stateless and
DHCP, what happens if the DHCP server *omits* that address the next
time the client renews an IA? Should the client now assume the address
is no longer valid? But does it then also need to remember that it
learned that address via stateless addrconf, and shouldn't invalidate
it?

To me, it seems cleanest to say all addresses have explicit
lifetimes, and the only way to invalidate an address is:

1) have the lifetime go to zero (something the client does should it
   not receive an updated lifetime via DHCP or stateless addrconf)

2) Use DHCP or stateless addrconf to send an update with new lifetimes
   that force step 1) to happen more quickly in those cases where this
   is the desired outcome.

Here is specific scenario where the invalidate implicitely model may
result in incorrect behavior. Consider a misconfiguration where the
same address is being advertised via stateless and DHCP. Suppose the
sys admin determines the misconfiguration and attempts to correct it
by having address/prefix advertised only via statless. The sys admin
then updates the DHCP config file and on the next DHCP update, the
DHCP server omits the address at question. In this case, you do not
want the client to invalidate the address, as it is also being
advertised by stateless. But the client would have already forgotten
that information, unless it remembered the last router advertisement
(something that it is not required to do). If the DHCP semantics were
that an address becomes invalidated only when the lifetime reaches
zero, having DHCP stop advertising the prefix would not cause the
client (in this case) to improperly stop using and address. On the
other hand, if the DHCP semantics resulted in invalidating an address
through omission of the address, the client would invalidate the
address immediately, and it would not become valid again until it
received a new advertisement via stateless (this can take as long as
30 minutes, BTW).

Thomas   



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 07:58:46 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00665;
	Mon, 25 Sep 2000 07:58:46 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PBvub20560;
	Mon, 25 Sep 2000 07:57:56 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PBvTb30750
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 07:57:29 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NMMY>; Mon, 25 Sep 2000 07:57:12 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC199@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Mon, 25 Sep 2000 07:57:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Thomas:

The model I was proposing handles your situations. The DHCP server need NOT
supply the address in a renewal, but that does NOT mean that the client
should stop using that address. The client can continue to use that address
until the lifetime expires.

If the DHCP Server wants to stop the client from using the address 'now', it
can do that by supplying a small (or 0) lifetime in the renewal. (The
lifetime depends on what we'll allow the server to specify for lifetimes and
how secure the client feels about what it receives from the server).

The Server could use the following technique to remove an address:
- Signal client to reconfigure
- When client renews, send the address with a 0 lifetime

If an address (prefix) is otherwise removed from a DHCP server
configuration, the server would simply not include that address in future
replies to the client. However, the client has full rights to use that
address until the lifetime expires.

BTW: It would not surprise me that Router Advertisements will advertise
stateful prefixes (that was the design as there is a bit that specifies
whether a client can autoconfigure from that prefix). That is one reason why
I raised the issue early on that we need to be clear about how a client
should handle this in general. What if a DHCP Server says that preferred
lifetime is 20 hours and valid is 60 hours and Router Advertisements say 2
and 6 hours, respectively? Which should the client use? And depending on how
you chose, consider what happens if the renewal time is 10 hours.

- Bernie Volz

-----Original Message-----
From: Thomas Narten [mailto:narten@raleigh.ibm.com]
Sent: Monday, September 25, 2000 7:35 AM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...


Ted Lemon <mellon@nominum.com> writes:

> > Or, one can be silent (omit an address), but that *does* *not*
> > invalidate the address and cause the client to stop using it per
> > se. Rather, the client stops using an address when the addresses'
> > valid lifetime goes to zero.

> The way we have talked about this, the client remembers all its
> addresses, and the absence of one of these addresses in the response
> for an IA indicates that the client should stop using the address
> immediately.

One reason why the above semantics are perhaps not ideal concerns when
both stateless addrconf *and* DHCPv6 happen to be sending out
information about the same address. Sure, one can argue that this is a
misconfiguration, but it will happen sometimes, and the protocol needs
to define the correct behavior in that case. The addrconf spec says
that in all cases, whenever a node gets "new" information (either from
stateless addrconf or DHCP) that new information becomes definitive
and supercedes any information about that address received in the
past. Thus, a "new" DHCP update always overrides a previous stateless
addrconf advertisement and vice versa.  This choice was made to keep
things simple, as it removes corner cases having to do when deciding
whether to believe stateless over DHCP or vice versa.

For example, if an address is being advertised by both stateless and
DHCP, what happens if the DHCP server *omits* that address the next
time the client renews an IA? Should the client now assume the address
is no longer valid? But does it then also need to remember that it
learned that address via stateless addrconf, and shouldn't invalidate
it?

To me, it seems cleanest to say all addresses have explicit
lifetimes, and the only way to invalidate an address is:

1) have the lifetime go to zero (something the client does should it
   not receive an updated lifetime via DHCP or stateless addrconf)

2) Use DHCP or stateless addrconf to send an update with new lifetimes
   that force step 1) to happen more quickly in those cases where this
   is the desired outcome.

Here is specific scenario where the invalidate implicitely model may
result in incorrect behavior. Consider a misconfiguration where the
same address is being advertised via stateless and DHCP. Suppose the
sys admin determines the misconfiguration and attempts to correct it
by having address/prefix advertised only via statless. The sys admin
then updates the DHCP config file and on the next DHCP update, the
DHCP server omits the address at question. In this case, you do not
want the client to invalidate the address, as it is also being
advertised by stateless. But the client would have already forgotten
that information, unless it remembered the last router advertisement
(something that it is not required to do). If the DHCP semantics were
that an address becomes invalidated only when the lifetime reaches
zero, having DHCP stop advertising the prefix would not cause the
client (in this case) to improperly stop using and address. On the
other hand, if the DHCP semantics resulted in invalidating an address
through omission of the address, the client would invalidate the
address immediately, and it would not become valid again until it
received a new advertisement via stateless (this can take as long as
30 minutes, BTW).

Thomas   



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 08:05:38 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00900;
	Mon, 25 Sep 2000 08:05:38 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PC53b12255;
	Mon, 25 Sep 2000 08:05:04 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PC4ab10400
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 08:04:41 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NMM7>; Mon, 25 Sep 2000 08:04:21 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC19A@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: FW: DHCP server startup announcement
Date: Mon, 25 Sep 2000 08:04:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Folks ... (I think there may have been a previous discussion on the V6 list
about this but I could be wrong), but should we not consider perhaps a
better model than having clients periodically send SOLICIT messages?

Perhaps a "Server-Started" message could be use instead? This would notify
clients that are on the link that a server is present and that they may want
to retry SOLICITs.

Now, while this works well for clients that are on the same physical link,
it is less clear how this would work when relays are included in the
configuration (especially if the relays are also not on the same physical
link as the server).

So, perhaps this is a brain-dead idea because of these issues.

- Bernie Volz

-----Original Message-----
From: Erik Guttman [mailto:Erik.Guttman@germany.sun.com] 
Sent: Monday, September 25, 2000 3:00 AM
To: DHCPv4 discussion list
Cc: DHCPv4 discussion list
Subject: Re: DHCP server startup announcement



Stuart Cheshire wrote:
> When a DHCP client fails to find a DHCP server, it typically keeps 
> broadcasting DHCP DISCOVERs at a low rate (e.g. one every five minutes).
...
> One thought that occurs to me is that we could borrow from 
> draft-ietf-dhc-pv4-reconfigure-01.txt -- the server could broadcast a 
> FORCERENEW (perhaps with all zeroes in the chaddr field) effectively 
> saying, "To any client that currently has no server-assigned address, and 
> would like one, a server is now available for you to send a DISCOVER."

I fully support this direction.  This will make it much easier for
auto configured clients to discover DHCP servers.  One of the problems
with the 'polling model' is that devices will discover the DHCP server
at different times.  During this 'transition' phase, some devices could
potentially be unable to communicate.  This could be avoided by having
devices discover the DHCP server through an announcement and transition
en masse.  Considering that - there should be some randomizing interval
so that hosts that receive the FORCERENEW don't all try to hit the DHCP
server at once :-)

Erik



From owner-dhcp-v4@bucknell.edu  Mon Sep 25 08:08:35 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00964
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 25 Sep 2000 08:08:35 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PC7Ib12148;
	Mon, 25 Sep 2000 08:07:18 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PC73b28435
	for <dhcp-v4@bucknell.edu>; Mon, 25 Sep 2000 08:07:03 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NMM0>; Mon, 25 Sep 2000 08:06:48 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC19B@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: DHCP server startup announcement
Date: Mon, 25 Sep 2000 08:06:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Volz@ipworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

FYI - This won't work completely because while great for clients that are on
the same physical link as the server, what happens if the server and clients
aren't on the same link (broadcast can't reach the clients). While relays
that are on the same physical link  as the server, could forward, there are
likely relays that will not be and they won't receive the broadcast.

One option might be for the server to send a directed broadcast to all of
the networks it is configured to support. (Perhaps the reconfigure-01.txt
draft already says that).

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Erik Guttman [mailto:Erik.Guttman@germany.sun.com]
Sent: Monday, September 25, 2000 3:00 AM
To: DHCPv4 discussion list
Cc: DHCPv4 discussion list
Subject: Re: DHCP server startup announcement



Stuart Cheshire wrote:
> When a DHCP client fails to find a DHCP server, it typically keeps 
> broadcasting DHCP DISCOVERs at a low rate (e.g. one every five minutes).
...
> One thought that occurs to me is that we could borrow from 
> draft-ietf-dhc-pv4-reconfigure-01.txt -- the server could broadcast a 
> FORCERENEW (perhaps with all zeroes in the chaddr field) effectively 
> saying, "To any client that currently has no server-assigned address, and 
> would like one, a server is now available for you to send a DISCOVER."

I fully support this direction.  This will make it much easier for
auto configured clients to discover DHCP servers.  One of the problems
with the 'polling model' is that devices will discover the DHCP server
at different times.  During this 'transition' phase, some devices could
potentially be unable to communicate.  This could be avoided by having
devices discover the DHCP server through an announcement and transition
en masse.  Considering that - there should be some randomizing interval
so that hosts that receive the FORCERENEW don't all try to hit the DHCP
server at once :-)

Erik



From owner-dhcp-v4@bucknell.edu  Mon Sep 25 09:53:41 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03612
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 25 Sep 2000 09:53:41 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PDn5b22697;
	Mon, 25 Sep 2000 09:49:05 -0400 (EDT)
Received: from honts307.wal-mart.com (honts307.wal-mart.com [146.132.234.37])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PDmxb29766
	for <dhcp-v4@bucknell.edu>; Mon, 25 Sep 2000 09:48:59 -0400 (EDT)
Received: from fwnts002-dmz.wal-mart.com ([146.132.238.59]) by honts307.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id S5586JG8; Mon, 25 Sep 2000 08:48:43 -0500
Received: from honts386.homeoffice.wal-mart.com by fwnts002-dmz.wal-mart.com
          via smtpd (for mailout.wal-mart.com [146.132.235.35]) with SMTP; 25 Sep 2000 13:48:43 UT
Received: from honts305.homeoffice.wal-mart.com (unverified) by honts386.homeoffice.wal-mart.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc0a8e0871ae4edd3e13fb@honts386.homeoffice.wal-mart.com>;
 Mon, 25 Sep 2000 08:41:22 -0500
Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21)
	id <TNF5WLGD>; Mon, 25 Sep 2000 08:48:43 -0500
Message-ID: <D3EA66988D05D411BFFB00A0C9899382468218@honts333.homeoffice.wal-mart.com>
From: Nathan Lane <ndlane@wal-mart.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: DHCP option codes 
Date: Mon, 25 Sep 2000 08:47:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Reply-To: ndlane@wal-mart.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I'll take it.

-Nathan Lane
Wal-Mart Stores, Inc.
(501) 277-5786


> -----Original Message-----
> From:	Thomas Narten [SMTP:narten@raleigh.ibm.com]
> Sent:	Thursday, September 21, 2000 6:08 PM
> To:	DHCPv4 discussion list
> Cc:	DHCPv4 discussion list
> Subject:	Re: DHCP option codes 
> 
> Stuart Cheshire <cheshire@apple.com> writes:
> 
> > IANA lists all the currently assigned DHCP option codes:
> 
> > <http://www.isi.edu/in-notes/iana/assignments/bootp-dhcp-parameters>
> 
> > I was just taking a quick look through the list to see if there are any 
> > obvious omissions in Mac OS that we ought to fix, but it is hard to tell
> 
> > because the list doesn't give the RFCs that define the format and usage 
> > of each option. Is such a list available anywhere?
> 
> I've wanted such a list in the past too.  This is something IANA ought
> to do. I.e., for all assigned numbers, point to the RFC defining
> it. It would probably be a help to IANA (read: it would happen sooner)
> if this WG would do this for them, or at least a first cut.
> 
> Any takers?
> 
> Thomas


**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to 
whom they are addressed.  If you have received this email 
in error destroy it immediately.
**********************************************************************



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 10:18:46 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04104;
	Mon, 25 Sep 2000 10:18:46 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PEIEb01882;
	Mon, 25 Sep 2000 10:18:15 -0400 (EDT)
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PEHxb11279
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 10:17:59 -0400 (EDT)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA12488
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 10:17:42 -0400
Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA31632
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 10:17:42 -0400
Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id KAA16079 for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 10:17:36 -0400
Message-Id: <200009251417.KAA16079@rotala.raleigh.ibm.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 o n Co nference Call Agenda) 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Fri, 08 Sep 2000 08:19:57 EDT." <63D30D6E10CFD11190A90000F805FE8602BEC0E3@lespaul.process.com> 
Date: Mon, 25 Sep 2000 10:17:36 -0400
From: Thomas Narten <narten@RALEIGH.IBM.COM>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Responding to some very old mail...

Bernie Volz <Volz@ipworks.com> writes:

> BTW: If there are no router advertisements received (after some period), I
> assume a IPv6 host is supposed to attempt stateful address configuration (by
> default).

RFC 2462 sez:

5.5.2.  Absence of Router Advertisements

   If a link has no routers, a host MUST attempt to use stateful
   autoconfiguration to obtain addresses and other configuration
   information. An implementation MAY provide a way to disable the
   invocation of stateful autoconfiguration in this case, but the
   default SHOULD be enabled.  From the perspective of
   autoconfiguration, a link has no routers if no Router Advertisements
   are received after having sent a small number of Router Solicitations
   as described in [DISCOVERY].

Thomas



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 10:23:13 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04177;
	Mon, 25 Sep 2000 10:23:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PEMdb25781;
	Mon, 25 Sep 2000 10:22:39 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PEMOb30739
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 10:22:24 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA02192;
	Mon, 25 Sep 2000 07:22:20 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id HAA13261;
	Mon, 25 Sep 2000 07:22:12 -0700 (PDT)
Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18])
	by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8PEMBa834880;
	Mon, 25 Sep 2000 07:22:11 -0700 (PDT)
Date: Thu, 21 Sep 2000 13:02:21 -0700 (PDT)
From: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Subject: Re: DHCPv6 address model proposal... 
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>,
        DHCPv6 discussion list <dhcp-v6@bucknell.edu>
In-Reply-To: "Your message with ID" <200009210704.e8L74t309418@grosse.bisbee.fugue.com>
Message-ID: <Roam.SIMC.2.0.6.969566541.14027.nordmark@jurassic>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

> 
> > Hmm, it isn't obvious that we need another way to invalidate an address
> > (by leaving it out from the IA). Isn't it sufficient to be explicit about
> > invalidating an address by including it with a zero valid and preferred
> > lifetime?
> 
> This requires the server to remember that the client had that address,
> so it's actually not a simplification - it makes additional work for
> the server, which now has to track the administrative removal of
> non-renewable addresses.

Got it. Thanks.

  Erik



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 11:38:43 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06241;
	Mon, 25 Sep 2000 11:38:43 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PFZib25568;
	Mon, 25 Sep 2000 11:35:48 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PFZXb06127
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 11:35:33 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id CBF171341; Mon, 25 Sep 2000 10:35:17 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 8458213AB
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 10:35:17 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id LAA0000690395; Mon, 25 Sep 2000 11:34:33 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009251534.LAA0000690395@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Mon, 25 Sep 2000 06:50:50 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC197@lespaul.process.com> 
Date: Mon, 25 Sep 2000 11:34:33 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>Jim ... I think you have it. If the server's reply does not include an
>address that the client previously had for that IA, the client should follow
>the normal rules and continue using that address until the lifetimes expire.
>
>This is just like stateless addrconf.

Exactly.  We cannot break existing Ipv6 implementations either with
DHCPv6 or rebuild the stateless architecture at this point.
Not that anyone has proposed that but want to make sure  we as a group
understand any boundaries we have for IPv6.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 12:15:15 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07441;
	Mon, 25 Sep 2000 12:15:14 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PGCqb31068;
	Mon, 25 Sep 2000 12:12:52 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PGCfb00315
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 12:12:41 -0400 (EDT)
Received: from rdroms-nt.bucknell.edu (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA02308 for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 12:12:25 -0400 (EDT)
Message-Id: <4.3.1.2.20000925120645.00bb9c70@mail.bucknell.edu>
X-Sender: droms@mail.bucknell.edu
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 25 Sep 2000 12:14:40 -0400
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
From: Ralph Droms <droms@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: <200009251135.HAA11579@hygro.adsl.duke.edu>
References: <Message from Ted Lemon <mellon@nominum.com>
 <200009221743.e8MHhOw00654@grosse.bisbee.fugue.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Tomas - in general I see your point.  In the particular case you cite:

At 07:35 AM 9/25/00 -0400, Thomas Narten wrote:
>For example, if an address is being advertised by both stateless and
>DHCP, what happens if the DHCP server *omits* that address the next
>time the client renews an IA? Should the client now assume the address
>is no longer valid? But does it then also need to remember that it
>learned that address via stateless addrconf, and shouldn't invalidate
>it?

According to the stateful/stateless interaction rule: "a "new" DHCP update 
always overrides a previous stateless addrconf advertisement and vice 
versa."  I would interpret that rule to say that the DHCP message overrides 
the stateless addrconf and the client should invalidate the address...

The more interesting case might be if a stateless addrconf message 
advertises a prefix unknown to the DHCP server.  In the case of implicit 
invalidation ("invalidation b omission"), what does the client do if the 
DHCP server does not return an address within that prefix in the IA?

Here's another interesting case: what does the client do in the server 
explicitly invalidates an address within a prefix advertised by stateless 
addrconf?

Under what circumstances would a host be using both stateful and stateless 
addrconf?

Of course, I may be confused about the operation of stateless addrconf; 
please feel free to correct me (as gently as possible!)...

- Ralph



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 12:21:10 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07694;
	Mon, 25 Sep 2000 12:21:10 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PGKmb25966;
	Mon, 25 Sep 2000 12:20:48 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PGKfb16144
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 12:20:41 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id FAA06846; Sun, 24 Sep 2000 05:45:09 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PGIlp00938; Mon, 25 Sep 2000 09:18:47 -0700 (MST)
Message-Id: <200009251618.e8PGIlp00938@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
cc: dhcp-v6@bucknell.edu
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Jim Bound <bound@zk3.dec.com> 
   of "Sun, 24 Sep 2000 23:24:40 -0400." <200009250324.XAA0000627106@anw.zk3.dec.com> 
Date: Mon, 25 Sep 2000 09:18:47 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> So what I am stating is that if the server sends back a Reply and there
> is no address in the packet which the client is still using and received
> from DHCPv6 the client cannot break the IPv6 connections using that address 
> per the rules defined in stateless addrconf.

Yes, I understand that.   But you are talking about an implementation
detail, rather than about a goal.   It seems like the goal is that the
protocol should not cause a client to drop an address when it doesn't
have to.    Right?

I'm very uncomfortable with drawing parallels to stateless address
configuration.   The current draft does things the way stateless
address configuration does them, and because this is a state*ful*
protocol and not a state*less* one, this makes the protocol more
difficult to understand and implement than it needs to be, IMHO.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 12:30:45 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07834;
	Mon, 25 Sep 2000 12:30:45 -0400 (EDT)
Received: from localhost (LOCALHOST [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PGUHb12298;
	Mon, 25 Sep 2000 12:30:18 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PGTvb19283
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 12:29:58 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id FAA06871 for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 05:54:25 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PGSgp01068 for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 09:28:42 -0700 (MST)
Message-Id: <200009251628.e8PGSgp01068@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Mon, 25 Sep 2000 06:47:13 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC196@lespaul.process.com> 
Date: Mon, 25 Sep 2000 09:28:42 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> I believe that it is generally useful and should be required of the client
> if it has any addresses for which the lifetimes have not "expired".

Right, but why do you believe this?   We're talking about a lot of
bytes, and a lot of extra processing on the server, so I'd like to see
some justification for why this is useful.   Can you give me an
example where the server's behaviour would change based on this
information?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 12:33:56 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07933;
	Mon, 25 Sep 2000 12:33:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PGXYb11457;
	Mon, 25 Sep 2000 12:33:34 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PGXLb04573
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 12:33:21 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id FAA06887 for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 05:57:51 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PGW7p01125 for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 09:32:07 -0700 (MST)
Message-Id: <200009251632.e8PGW7p01125@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Thomas Narten <narten@RALEIGH.IBM.COM> 
   of "Mon, 25 Sep 2000 07:35:28 -0400." <200009251135.HAA11579@hygro.adsl.duke.edu> 
Date: Mon, 25 Sep 2000 09:32:07 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


Okay, I think I can agree then that the absence of an address in a
DHCPreply should not cause the client to drop that address.  I prefer
the other way, but don't have a strong reason for preferring it, and
you've given a good reason for preferring this way.   :'}

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 12:47:55 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08190;
	Mon, 25 Sep 2000 12:47:54 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PGjIb04388;
	Mon, 25 Sep 2000 12:45:18 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PGj5b28049
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 12:45:05 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id AFD2E6F1; Mon, 25 Sep 2000 12:44:57 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP
	id 98B892934; Mon, 25 Sep 2000 12:44:57 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id MAA0000696990; Mon, 25 Sep 2000 12:43:38 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009251643.MAA0000696990@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: dhcp-v6@bucknell.edu
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Mon, 25 Sep 2000 09:18:47 PDT."
             <200009251618.e8PGIlp00938@grosse.bisbee.fugue.com> 
Date: Mon, 25 Sep 2000 12:43:38 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>> So what I am stating is that if the server sends back a Reply and there
>> is no address in the packet which the client is still using and received
>> from DHCPv6 the client cannot break the IPv6 connections using that address 
>> per the rules defined in stateless addrconf.
>
>Yes, I understand that.   But you are talking about an implementation
>detail, rather than about a goal.   It seems like the goal is that the
>protocol should not cause a client to drop an address when it doesn't
>have to.    Right?

Yes that is right.  But I do think we will get into situations in the
spec where we can either be silent or state what is to happen.  I think
the mail Ralph just sent to Thomas on stateless will open more light to
this issue for discussion.  I will not respond and let Thomas respond.
Having implemented stateless this is very tricky stuff and what I would
hope is we learn from that experience and from all the IPv6
implementors.

But I am in agreement with Bernies comments in this space and issues.
For the protocol specification. 

>I'm very uncomfortable with drawing parallels to stateless address
>configuration.   The current draft does things the way stateless
>address configuration does them, and because this is a state*ful*
>protocol and not a state*less* one, this makes the protocol more
>difficult to understand and implement than it needs to be, IMHO.

I think we need to just make sure we don't break stateless stuff and why
I think we are groking all this now.  In defense of the current draft we
did add the stateful parts where appropriate.  But we are now trying to
reduce complexity with things like the IA.  So I think we will reach
less complexity from the mail I see.  But we cannot ignore the stateful
effect to implementations of stateless is the key point we must make
sure in our design choices for the next version of dhcpv6.

But Mike will send out some questions we have today on all the threads
so we can write this stuff down.  One will be the entire IA use and
definition and lots of questions and clarification of that.  For now I
am just assuming it will work and treating it as opaque but we need to
have detailed discussion of the IA.

regards,
/jim
			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 13:02:28 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08500;
	Mon, 25 Sep 2000 13:02:28 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PH23b08834;
	Mon, 25 Sep 2000 13:02:03 -0400 (EDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PH1xb09206
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 13:01:59 -0400 (EDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 415926209; Mon, 25 Sep 2000 13:01:43 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id 290DFB78
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 13:01:43 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id NAA0000698240; Mon, 25 Sep 2000 13:01:42 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009251701.NAA0000698240@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: NOTE on October dates not good for IPv6 folks
Date: Mon, 25 Sep 2000 13:01:42 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ralph,

FYI many of us will be at the IPv6 U.S. Summit on Oct 18-20 in Wash D.C.
so if we plan meetings I ask they not happen at this time.  We will be
missing a few of us and both ADs (Thomas is speaking here too) and I
assume Erik will be there too.  I have to be there as Chair of the IPv6 
Forum Technical Directorate and many of those folks will be there I hope 
too like Francis Dupont and other IPv6 implementors.
http://www.ipv6forum.com/ (tech directorate listed here on the page)

Here is URL of the event too if folks want to attend.
http://www.xiwt.org/XIWT-IPv6/meetingsite.html

The target audience for this particular IPv6 Summit are the ISPs and
Telco providers.

thanks
/jim



From owner-dhcp-v4@bucknell.edu  Mon Sep 25 13:29:15 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08999
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 25 Sep 2000 13:29:15 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PHP9b13225;
	Mon, 25 Sep 2000 13:25:09 -0400 (EDT)
Received: from west10.flashcom.com (d82020d0.hb.flashcom.com [216.32.32.208])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PHOxb05327
	for <dhcp-v4@bucknell.edu>; Mon, 25 Sep 2000 13:24:59 -0400 (EDT)
Received: by d82020d0.hb.flashcom.com with Internet Mail Service (5.5.2650.21)
	id <TT4176DT>; Mon, 25 Sep 2000 10:32:23 -0700
Message-ID: <3F9ACFADAA5BD411B35000D0B7471E3B0440D0@d82020d0.hb.flashcom.com>
From: Jerry Roy <jroy@flashcom.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: DHCP server startup announcement
Date: Mon, 25 Sep 2000 10:32:22 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: jroy@flashcom.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hello all,

Why not have the DHCP relays that the DHCP Server hears from have a
mechanism that allows the relay to forward the "server available" only out
onto the segments that the relay has responsibility.

Best Regards,

Jerry Roy
Flashcom, Inc.

-----Original Message-----
From: Bernie Volz [mailto:Volz@ipworks.com]
Sent: Monday, September 25, 2000 5:07 AM
To: DHCPv4 discussion list
Subject: RE: DHCP server startup announcement


FYI - This won't work completely because while great for clients that are on
the same physical link as the server, what happens if the server and clients
aren't on the same link (broadcast can't reach the clients). While relays
that are on the same physical link  as the server, could forward, there are
likely relays that will not be and they won't receive the broadcast.

One option might be for the server to send a directed broadcast to all of
the networks it is configured to support. (Perhaps the reconfigure-01.txt
draft already says that).

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Erik Guttman [mailto:Erik.Guttman@germany.sun.com]
Sent: Monday, September 25, 2000 3:00 AM
To: DHCPv4 discussion list
Cc: DHCPv4 discussion list
Subject: Re: DHCP server startup announcement



Stuart Cheshire wrote:
> When a DHCP client fails to find a DHCP server, it typically keeps 
> broadcasting DHCP DISCOVERs at a low rate (e.g. one every five minutes).
...
> One thought that occurs to me is that we could borrow from 
> draft-ietf-dhc-pv4-reconfigure-01.txt -- the server could broadcast a 
> FORCERENEW (perhaps with all zeroes in the chaddr field) effectively 
> saying, "To any client that currently has no server-assigned address, and 
> would like one, a server is now available for you to send a DISCOVER."

I fully support this direction.  This will make it much easier for
auto configured clients to discover DHCP servers.  One of the problems
with the 'polling model' is that devices will discover the DHCP server
at different times.  During this 'transition' phase, some devices could
potentially be unable to communicate.  This could be avoided by having
devices discover the DHCP server through an announcement and transition
en masse.  Considering that - there should be some randomizing interval
so that hosts that receive the FORCERENEW don't all try to hit the DHCP
server at once :-)

Erik



From owner-dhcp-v4@bucknell.edu  Mon Sep 25 13:51:04 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09363
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 25 Sep 2000 13:51:04 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PHmcb00967;
	Mon, 25 Sep 2000 13:48:38 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PHmPb25913
	for <dhcp-v4@bucknell.edu>; Mon, 25 Sep 2000 13:48:25 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id HAA07149; Sun, 24 Sep 2000 07:12:53 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PHkxp02169; Mon, 25 Sep 2000 10:46:59 -0700 (MST)
Message-Id: <200009251746.e8PHkxp02169@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP server startup announcement 
In-Reply-To: Message from Jerry Roy <jroy@flashcom.com> 
   of "Mon, 25 Sep 2000 10:32:22 MST." <3F9ACFADAA5BD411B35000D0B7471E3B0440D0@d82020d0.hb.flashcom.com> 
Date: Mon, 25 Sep 2000 10:46:58 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Why not have the DHCP relays that the DHCP Server hears from have a
> mechanism that allows the relay to forward the "server available" only out
> onto the segments that the relay has responsibility.

The DHCP relay agent is the sacred cow of the DHCP protocol - a lot of
backwards-bending was done to avoid having to modify them.   So
they're basically pretty stupid devices, and having them do this
probably wouldn't work.

However, since the DHCP server has to know what networks it serves,
and since this is an optional feature, it might be okay to have the
DHCP server simply do directed broadcasts to each of the subnets it
supports.

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Mon Sep 25 14:21:48 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09963
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 25 Sep 2000 14:21:48 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PIIkb26214;
	Mon, 25 Sep 2000 14:18:46 -0400 (EDT)
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PIIXb17765
	for <dhcp-v4@bucknell.edu>; Mon, 25 Sep 2000 14:18:33 -0400 (EDT)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA23932;
	Mon, 25 Sep 2000 14:18:13 -0400
Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA31420;
	Mon, 25 Sep 2000 14:18:14 -0400
Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA17126; Mon, 25 Sep 2000 14:18:06 -0400
Message-Id: <200009251818.OAA17126@rotala.raleigh.ibm.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP server startup announcement 
In-Reply-To: Message from Ted Lemon <mellon@nominum.com> 
   of "Mon, 25 Sep 2000 10:46:58 PDT." <200009251746.e8PHkxp02169@grosse.bisbee.fugue.com> 
Date: Mon, 25 Sep 2000 14:18:06 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Reply-To: narten@raleigh.ibm.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

> However, since the DHCP server has to know what networks it serves,
> and since this is an optional feature, it might be okay to have the
> DHCP server simply do directed broadcasts to each of the subnets it
> supports.

Operationally, enablement of directed broadcast is frowned upon these
days, as it enables a class of DOS attacks (e.g., smurf attacks).

THomas



From owner-dhcp-v4@bucknell.edu  Mon Sep 25 14:25:55 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10145
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 25 Sep 2000 14:25:55 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PINZb14396;
	Mon, 25 Sep 2000 14:23:35 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PINLb01468
	for <dhcp-v4@bucknell.edu>; Mon, 25 Sep 2000 14:23:21 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id HAA07268; Sun, 24 Sep 2000 07:47:50 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PILwp02698; Mon, 25 Sep 2000 11:21:58 -0700 (MST)
Message-Id: <200009251821.e8PILwp02698@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP server startup announcement 
In-Reply-To: Message from Thomas Narten <narten@raleigh.ibm.com> 
   of "Mon, 25 Sep 2000 14:18:06 -0400." <200009251818.OAA17126@rotala.raleigh.ibm.com> 
Date: Mon, 25 Sep 2000 11:21:57 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


Mark Sirota suggested offline that one could just use the relay
agent's broadcast bit capability to send the packet to the local
subnet.  The main problem with this is that it means you have to
configure the server with the IP addresses of all the relay agents.
OTOH, the server may already know all their IP addresses, in an
environment where relay agents are all running on embedded routers -
certainly the most common case.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 14:32:38 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10307;
	Mon, 25 Sep 2000 14:32:38 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PIVLb10635;
	Mon, 25 Sep 2000 14:31:21 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PIUeb02223
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 14:30:40 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NNCM>; Mon, 25 Sep 2000 14:30:22 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC1A0@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Mon, 25 Sep 2000 14:30:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted ... as you cut and paste messages, it is often difficult to recall the
exact context.

I believe you are asking why the client should be sending all of its
addresses in a renewal?

If so, I already gave you my reasons. It is important for:
- Failover - lazy update would not work otherwise
- Multiple server situations
- Loss of server's stable storage

These are *ALL* examples of where the server's behavoir (under certain
circumstances) would be changed based on this information because if it
wasn't there the renewal might get completely different addresses UNLESS you
tell me that the way a server "calculates" an address is a fixed algorithm
(in which case why have the IA at all as we want to be able to give the
client multiple addresses).

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Monday, September 25, 2000 12:29 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...



> I believe that it is generally useful and should be required of the client
> if it has any addresses for which the lifetimes have not "expired".

Right, but why do you believe this?   We're talking about a lot of
bytes, and a lot of extra processing on the server, so I'd like to see
some justification for why this is useful.   Can you give me an
example where the server's behaviour would change based on this
information?

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Mon Sep 25 14:37:29 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10404
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 25 Sep 2000 14:37:28 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PIa5b08186;
	Mon, 25 Sep 2000 14:36:05 -0400 (EDT)
Received: from Arachnid.NTRG.com ([209.31.7.46])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PIZwb18677
	for <dhcp-v4@bucknell.edu>; Mon, 25 Sep 2000 14:35:58 -0400 (EDT)
Received: from ehsco.com (ferret.ntrg.com [192.168.10.10])
          by Arachnid.NTRG.com (Netscape Messaging Server 3.62)  with ESMTP
          id 599; Mon, 25 Sep 2000 11:35:52 -0700
Message-ID: <39CF9B06.D6E92988@ehsco.com>
Date: Mon, 25 Sep 2000 11:35:50 -0700
From: "Eric A. Hall" <ehall@ehsco.com>
Organization: EHS Company
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
CC: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP server startup announcement
References: <200009251821.e8PILwp02698@grosse.bisbee.fugue.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: ehall@ehsco.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit


> Mark Sirota suggested offline that one could just use the relay
> agent's broadcast bit capability to send the packet to the local
> subnet.  The main problem with this is that it means you have to
> configure the server with the IP addresses of all the relay agents.
> OTOH, the server may already know all their IP addresses, in an
> environment where relay agents are all running on embedded routers -
> certainly the most common case.

Well, the multicast bootp relay extension would work with this too. The
server would only have to send the message to the multicast address that
the relay agents were listening on.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/



From owner-dhcp-v4@bucknell.edu  Mon Sep 25 14:43:41 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10653
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 25 Sep 2000 14:43:40 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PIgPb14494;
	Mon, 25 Sep 2000 14:42:25 -0400 (EDT)
Received: from honts308.wal-mart.com (honts308.wal-mart.com [146.132.234.38])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PIg8b18174
	for <dhcp-v4@bucknell.edu>; Mon, 25 Sep 2000 14:42:08 -0400 (EDT)
Received: from fwnts002-dmz.wal-mart.com ([146.132.238.59]) by honts308.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id TNK0HQDN; Mon, 25 Sep 2000 13:38:01 -0500
Received: from honts385.homeoffice.wal-mart.com by fwnts002-dmz.wal-mart.com
          via smtpd (for mailout.wal-mart.com [146.132.235.35]) with SMTP; 25 Sep 2000 18:38:01 UT
Received: from honts305.homeoffice.wal-mart.com (unverified) by honts385.homeoffice.wal-mart.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc0a8e0865c4ede49788f@honts385.homeoffice.wal-mart.com> for <dhcp-v4@bucknell.edu>;
 Mon, 25 Sep 2000 13:33:26 -0500
Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21)
	id <TT4JWLYN>; Mon, 25 Sep 2000 13:37:17 -0500
Message-ID: <D3EA66988D05D411BFFB00A0C9899382468221@honts333.homeoffice.wal-mart.com>
From: Nathan Lane <ndlane@wal-mart.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: DHCP server startup announcement 
Date: Mon, 25 Sep 2000 13:37:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Reply-To: ndlane@wal-mart.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> From:	Ted Lemon [SMTP:mellon@nominum.com]
> Subject:	Re: DHCP server startup announcement 
> 
> 
> Mark Sirota suggested offline that one could just use the relay
> agent's broadcast bit capability to send the packet to the local
> subnet.  The main problem with this is that it means you have to
> configure the server with the IP addresses of all the relay agents.
> OTOH, the server may already know all their IP addresses, in an
> environment where relay agents are all running on embedded routers -
> certainly the most common case.
> 
However, this could become complicated by many implementations that attach
the relay agent to the physical interfaces of a network instead of the
virtual in an HSRP or VRRP environment.  In an environment where more than a
simple pairing of HSRP or VRRP exists, we could introduce some serious
instabilities.  

Wouldn't this announcement have to be periodic to do any good anyway?

Finally, there is no relay agent on a secondarily assigned network.  I'm at
a loss at the moment to how this configuration would be handled.  (Some
relay agents will forward "spoofed" giaddrs, some will not.)

-Nathan Lane
>  			     


**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to 
whom they are addressed.  If you have received this email 
in error destroy it immediately.
**********************************************************************



From owner-dhcp-v4@bucknell.edu  Mon Sep 25 15:31:20 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11831
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 25 Sep 2000 15:31:20 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PJSDb32059;
	Mon, 25 Sep 2000 15:28:13 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PJRvb10955
	for <dhcp-v4@bucknell.edu>; Mon, 25 Sep 2000 15:27:57 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id IAA07464; Sun, 24 Sep 2000 08:52:25 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PJPDp03566; Mon, 25 Sep 2000 12:25:14 -0700 (MST)
Message-Id: <200009251925.e8PJPDp03566@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP server startup announcement 
In-Reply-To: Message from "Eric A. Hall" <ehall@ehsco.com> 
   of "Mon, 25 Sep 2000 11:35:50 MST." <39CF9B06.D6E92988@ehsco.com> 
Date: Mon, 25 Sep 2000 12:25:12 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Well, the multicast bootp relay extension would work with this too. The
> server would only have to send the message to the multicast address that
> the relay agents were listening on.

Wouldn't that wind up going back to the server, not to the client?   :'}

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 15:39:25 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11922;
	Mon, 25 Sep 2000 15:39:25 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PJcvb01509;
	Mon, 25 Sep 2000 15:38:57 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PJcmb01957
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 15:38:48 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id JAA07502 for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 09:03:17 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PJajp03718 for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 12:36:45 -0700 (MST)
Message-Id: <200009251936.e8PJajp03718@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Mon, 25 Sep 2000 14:30:21 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC1A0@lespaul.process.com> 
Date: Mon, 25 Sep 2000 12:36:45 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> These are *ALL* examples of where the server's behavoir (under certain
> circumstances) would be changed based on this information because if it
> wasn't there the renewal might get completely different addresses UNLESS you
> tell me that the way a server "calculates" an address is a fixed algorithm
> (in which case why have the IA at all as we want to be able to give the
> client multiple addresses).

If the client is renewing, it's unicasting to the server, not
broadcasting, right?   Actually, now that I think about it, I don't
know that this is true - do DHCPrequest messages go to the server's
address or to a multicast address?

Hm, this is interesting.  There does not appear to be a mechanism in
the specification for what happens if the client has a valid IA, tries
to renew it, and gets no response.   There doesn't seem to be anything
in the spec at all about renewal, other than a brief blurb on
releasable resources.

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Mon Sep 25 15:44:05 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12062
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 25 Sep 2000 15:44:04 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PJffb28747;
	Mon, 25 Sep 2000 15:41:41 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PJfNb26502
	for <dhcp-v4@bucknell.edu>; Mon, 25 Sep 2000 15:41:23 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id JAA07508; Sun, 24 Sep 2000 09:05:52 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PJdsp03763; Mon, 25 Sep 2000 12:39:55 -0700 (MST)
Message-Id: <200009251939.e8PJdsp03763@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP server startup announcement 
In-Reply-To: Message from Nathan Lane <ndlane@wal-mart.com> 
   of "Mon, 25 Sep 2000 13:37:15 EST." <D3EA66988D05D411BFFB00A0C9899382468221@honts333.homeoffice.wal-mart.com> 
Date: Mon, 25 Sep 2000 12:39:54 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> However, this could become complicated by many implementations that attach
> the relay agent to the physical interfaces of a network instead of the
> virtual in an HSRP or VRRP environment.  In an environment where more than a
> simple pairing of HSRP or VRRP exists, we could introduce some serious
> instabilities.  

In this case, the server has to know that this is going on.
Obviously it only needs to send to one of the router addresses on a
given physical network.

> Wouldn't this announcement have to be periodic to do any good anyway?

Nope.   If the server is up when the client comes up, the client will
discover it.  It's only if the server _isn't_ up when the client
starts that the client needs to get this message.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 16:05:55 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12452;
	Mon, 25 Sep 2000 16:05:54 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PK3Sb22739;
	Mon, 25 Sep 2000 16:03:28 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PK3Eb20362
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 16:03:15 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 3344F119A; Mon, 25 Sep 2000 15:02:58 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 8372D10DD
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 15:02:57 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id QAA0000713658; Mon, 25 Sep 2000 16:02:26 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009252002.QAA0000713658@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Mon, 25 Sep 2000 12:36:45 PDT."
             <200009251936.e8PJajp03718@grosse.bisbee.fugue.com> 
Date: Mon, 25 Sep 2000 16:02:26 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>If the client is renewing, it's unicasting to the server, not
>broadcasting, right?   Actually, now that I think about it, I don't
>know that this is true - do DHCPrequest messages go to the server's
>address or to a multicast address?

Nope.  Request is unicast only.  If you go to section 3 of the current
spec DHCP Constants you will see all the Multicast Addresses we use for
DHCPv6 and they are also all assigned by IANA as Bob Hinden did this for
the IPv6 Addr Arch.  But we never had request as Multicast.

>Hm, this is interesting.  There does not appear to be a mechanism in
>the specification for what happens if the client has a valid IA, tries
>to renew it, and gets no response.   There doesn't seem to be anything
>in the spec at all about renewal, other than a brief blurb on
>releasable resources.

Its also in 11.4.2 section under Request Retransmit.  The current specs
version of an IA is the link-local address + prefix for that link.  The
client does not try to renew the IA as the concept is new from our
design discussions.  The spec was written with the intention that
link-local and prefix of link will be unique and it is in IPv6, except
when a node changes its link-local now because of privacy concerns and
uses anonymous addresses.  I think we have a fix for this that can be
used by the IA too in our new design for the client identifier but that
should be its own mail message and thread and Mike should be sending
something on this as far as questions shortly.

So the client in the present spec does not have an IA to renew but we
did put in how to retransmit a request and I think we will have to do
the same with an IA.  

As far as releasable resources we stayed away from that except for the
actual address per the working groups input for sometime now.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 16:06:45 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12496;
	Mon, 25 Sep 2000 16:06:44 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PK6Qb25975;
	Mon, 25 Sep 2000 16:06:26 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PK6Eb32662
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 16:06:15 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NN23>; Mon, 25 Sep 2000 16:05:59 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC1A3@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Mon, 25 Sep 2000 16:05:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Yeah ... I looked through the spec the other day and couldn't find this
discussed either. I thought perhaps I just wasn't looking the right place.

Perhaps the DHCPv6 model is that the client must go back through the entire
cycle to locate a server? In that case, having the ability to provide a list
("gee, I'd like these addresses - can I have them please!") would be greatly
useful.

Sometimes I've been falling back into the DHCPv4 mode in our discussions ...
and in that case, certainly having the client send the address is absolutely
critical to the proper operation of DHCPv4 (we trust the client in failover
and at other times). And, as DHCPv6 has similar goals and requirements (at
least in my mind), I can't see how this fundamental issue should be changed.

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Monday, September 25, 2000 3:37 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...



> These are *ALL* examples of where the server's behavoir (under certain
> circumstances) would be changed based on this information because if it
> wasn't there the renewal might get completely different addresses UNLESS
you
> tell me that the way a server "calculates" an address is a fixed algorithm
> (in which case why have the IA at all as we want to be able to give the
> client multiple addresses).

If the client is renewing, it's unicasting to the server, not
broadcasting, right?   Actually, now that I think about it, I don't
know that this is true - do DHCPrequest messages go to the server's
address or to a multicast address?

Hm, this is interesting.  There does not appear to be a mechanism in
the specification for what happens if the client has a valid IA, tries
to renew it, and gets no response.   There doesn't seem to be anything
in the spec at all about renewal, other than a brief blurb on
releasable resources.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 17:04:25 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14014;
	Mon, 25 Sep 2000 17:04:24 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PL1hb19767;
	Mon, 25 Sep 2000 17:01:43 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PL1Xb17745
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 17:01:33 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id KAA07740 for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 10:26:02 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PKxsp04814 for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 13:59:59 -0700 (MST)
Message-Id: <200009252059.e8PKxsp04814@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Mon, 25 Sep 2000 16:02:26 -0400." <200009252002.QAA0000713658@anw.zk3.dec.com> 
Date: Mon, 25 Sep 2000 13:59:54 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> So the client in the present spec does not have an IA to renew but we
> did put in how to retransmit a request and I think we will have to do
> the same with an IA.  

Right, but what happens if the DHCP server the client contacted
previously is down when it tries to renew?   It can retry all it
wants, but it won't get a response.   Does it just time out and let
its connections die, or does it try to contact any other DHCP server
that may be present on the wire to see if it can get that DHCP server
to renew the IA with the same addresses?

This is the equivalent of the transition between RENEWING and
REBINDING in DHCPv4.   I don't see anything like that in the current
draft.   Is this omission intentional?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 17:07:52 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14140;
	Mon, 25 Sep 2000 17:07:51 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PL6Xb27255;
	Mon, 25 Sep 2000 17:06:33 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PL6Vb08515
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 17:06:31 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id KAA07752 for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 10:30:59 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PL4vp04888 for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 14:04:57 -0700 (MST)
Message-Id: <200009252104.e8PL4vp04888@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Mon, 25 Sep 2000 16:05:58 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC1A3@lespaul.process.com> 
Date: Mon, 25 Sep 2000 14:04:56 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> And, as DHCPv6 has similar goals and requirements (at
> least in my mind), I can't see how this fundamental issue should be changed.

When the client is contacting a server with which it has an existing
collection of addresses for an identity association, it should not be
necessary for it to resend its current addresses.  And if it is only
using its current addresses as care-of addresses, likewise I think it
doesn't need to send it.  However, if we can get into something like a
REBINDING state, *then* it needs to send its current set of addresses,
so that the other server in a failover pair has the opportunity to
renew them.

I don't think it needs to send its addresses on startup - in the
DHCPsolicit message - because at that time presumably it does not have
any outstanding connections on addresses in the identity association,
so it has nothing to lose if the secondary gives it a different
address.

So I see only one case where this is important: REBIND.   And the
current draft doesn't do REBIND.   I think it should do REBIND, and
when it does, I think the REBIND request should include a list of
addresses.   Would that satisfy your concern?   If we conclude that we
*don't* need REBIND, do you think there is a case where the client
still needs to send its current address list?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 17:41:45 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15083;
	Mon, 25 Sep 2000 17:41:45 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PLdRb09774;
	Mon, 25 Sep 2000 17:39:27 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PLdDb24642
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 17:39:13 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NNN7>; Mon, 25 Sep 2000 17:38:57 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC1A8@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Mon, 25 Sep 2000 17:38:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ted:

Your analysis I think covers the issue. The REBIND case is really the only
one. We have been taking about clients needing to "renew" the leases so
isn't that a REBIND?

If the client never goes back to the server to "renew" the addresses, then
we don't need to send them. And, agreed that we only need to send them in a
rebind case.

If a client has no addresses, it can't send them; I never expected them to
be sent in a SOLICIT.

- Bernie Volz
  IPWorks, Inc.


-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Monday, September 25, 2000 5:05 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...



> And, as DHCPv6 has similar goals and requirements (at
> least in my mind), I can't see how this fundamental issue should be
changed.

When the client is contacting a server with which it has an existing
collection of addresses for an identity association, it should not be
necessary for it to resend its current addresses.  And if it is only
using its current addresses as care-of addresses, likewise I think it
doesn't need to send it.  However, if we can get into something like a
REBINDING state, *then* it needs to send its current set of addresses,
so that the other server in a failover pair has the opportunity to
renew them.

I don't think it needs to send its addresses on startup - in the
DHCPsolicit message - because at that time presumably it does not have
any outstanding connections on addresses in the identity association,
so it has nothing to lose if the secondary gives it a different
address.

So I see only one case where this is important: REBIND.   And the
current draft doesn't do REBIND.   I think it should do REBIND, and
when it does, I think the REBIND request should include a list of
addresses.   Would that satisfy your concern?   If we conclude that we
*don't* need REBIND, do you think there is a case where the client
still needs to send its current address list?

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 18:42:56 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16648;
	Mon, 25 Sep 2000 18:42:54 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PMeRb01050;
	Mon, 25 Sep 2000 18:40:27 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PMeNb02151
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 18:40:23 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id MAA08013 for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 12:04:51 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8PMcep06075 for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 15:38:42 -0700 (MST)
Message-Id: <200009252238.e8PMcep06075@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Mon, 25 Sep 2000 17:38:56 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC1A8@lespaul.process.com> 
Date: Mon, 25 Sep 2000 15:38:40 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> The REBIND case is really the only one. We have been taking about
> clients needing to "renew" the leases so isn't that a REBIND?

No.  REBIND is when the client has already tried to renew the lease by
contacting the server from which it got the lease using a unicast
message.  Time is running out, so it decides to see if it can contact
another server using multicast (broadcast in the DHCPv4 case).
REBINDING and RENEWING are two distinct states, and REBINDING is
specifically for cases where the old server can't be contacted.

I do not think it is necessary for the client to send an address list
in the RENEWING case - only in the REBINDING case.

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Mon Sep 25 18:51:48 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16858
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 25 Sep 2000 18:51:48 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PMnrb07858;
	Mon, 25 Sep 2000 18:49:54 -0400 (EDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PMnlb31805
	for <dhcp-v4@bucknell.edu>; Mon, 25 Sep 2000 18:49:47 -0400 (EDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com
	with Novell_GroupWise; Mon, 25 Sep 2000 16:49:26 -0600
Message-Id: <s9cf8216.071@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Mon, 25 Sep 2000 16:49:23 -0600
From: "Mark Hinckley" <MHINCKLEY@novell.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP server startup announcement
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_2E76D566.B3D2B6B4"
Reply-To: MHINCKLEY@novell.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_2E76D566.B3D2B6B4
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

>> However, this could become complicated by many implementations that =
attach
>> the relay agent to the physical interfaces of a network instead of the
>> virtual in an HSRP or VRRP environment.  In an environment where more =
than a
>> simple pairing of HSRP or VRRP exists, we could introduce some serious
>> instabilities. =20
>
> In this case, the server has to know that this is going on.
> Obviously it only needs to send to one of the router addresses on a
> given physical network.
>
>> Wouldn't this announcement have to be periodic to do any good anyway?
>
> Nope.   If the server is up when the client comes up, the client will
> discover it.  It's only if the server _isn't_ up when the client
> starts that the client needs to get this message.
>
>                   _MelloN_

This is true in a perfectly connected world.  But if the server is up, and =
then a client comes up,
but the router between them is down temporarily, when will the discovery =
be done without
a periodic broadcast?   That is not to say there aren't other problems =
with periodic broadcasts.

--=_2E76D566.B3D2B6B4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type=
>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT: 6pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: =
2px">
<DIV>&gt;&gt; However, this could become complicated by many implementation=
s=20
that attach<BR>&gt;&gt; the relay agent to the physical interfaces of a =
network=20
instead of the<BR>&gt;&gt; virtual in an HSRP or VRRP environment.&nbsp; =
In an=20
environment where more than a<BR>&gt;&gt; simple pairing of HSRP or VRRP =
exists,=20
we could introduce some serious<BR>&gt;&gt; instabilities.&nbsp;=20
<BR>&gt;<BR>&gt; In this case, the server has to know that this is =
going=20
on.<BR>&gt; Obviously it only needs to send to one of the router addresses =
on=20
a<BR>&gt; given physical network.<BR>&gt;<BR>&gt;&gt; Wouldn't this =
announcement=20
have to be periodic to do any good anyway?<BR>&gt;<BR>&gt; Nope.&nbsp;&nbsp=
; If=20
the server is up when the client comes up, the client will<BR>&gt; =
discover=20
it.&nbsp; It's only if the server _isn't_ up when the client<BR>&gt; =
starts that=20
the client needs to get this message.<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
_MelloN_</DIV>
<DIV>&nbsp;</DIV>
<DIV>This is true in a perfectly connected world.&nbsp; But if the server =
is up,=20
and then a client comes up,</DIV>
<DIV>but the router between them is down temporarily, when will the =
discovery be=20
done without</DIV>
<DIV>a periodic broadcast?&nbsp;&nbsp; That is not to say there aren't =
other=20
problems with periodic broadcasts.</DIV>
<DIV><BR><BR>&nbsp;</DIV></BODY></HTML>

--=_2E76D566.B3D2B6B4--



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 19:51:05 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17657;
	Mon, 25 Sep 2000 19:51:04 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8PNm6b04247;
	Mon, 25 Sep 2000 19:48:06 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8PNm0b04992
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 19:48:00 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NNR0>; Mon, 25 Sep 2000 19:47:44 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC1A9@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Mon, 25 Sep 2000 19:47:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

OK (I guess I should brush up on my DHCP terminology). The only benefit from
sending the list in the RENEWING case is the case where the server has lost
stable storage. In that case, if would have NO record of the addresses and
would be forced to determine new ones. So, we can decide whether that one
case is worth it.

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Monday, September 25, 2000 6:39 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...



> The REBIND case is really the only one. We have been taking about
> clients needing to "renew" the leases so isn't that a REBIND?

No.  REBIND is when the client has already tried to renew the lease by
contacting the server from which it got the lease using a unicast
message.  Time is running out, so it decides to see if it can contact
another server using multicast (broadcast in the DHCPv4 case).
REBINDING and RENEWING are two distinct states, and REBINDING is
specifically for cases where the old server can't be contacted.

I do not think it is necessary for the client to send an address list
in the RENEWING case - only in the REBINDING case.

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Mon Sep 25 20:16:45 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18094
	for <DHC-ARCHIVE@odin.ietf.org>; Mon, 25 Sep 2000 20:16:45 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8Q0FNb28043;
	Mon, 25 Sep 2000 20:15:23 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8Q0FGb06398
	for <dhcp-v4@bucknell.edu>; Mon, 25 Sep 2000 20:15:16 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id NAA08322; Sun, 24 Sep 2000 13:39:45 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8Q0DQp07364; Mon, 25 Sep 2000 17:13:27 -0700 (MST)
Message-Id: <200009260013.e8Q0DQp07364@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP server startup announcement 
In-Reply-To: Message from "Mark Hinckley" <MHINCKLEY@novell.com> 
   of "Mon, 25 Sep 2000 16:49:23 CST." <s9cf8216.071@prv-mail20.provo.novell.com> 
Date: Mon, 25 Sep 2000 17:13:26 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> This is true in a perfectly connected world.  But if the server is up, and =
> then a client comes up,
> but the router between them is down temporarily, when will the discovery =
> be done without
> a periodic broadcast?   That is not to say there aren't other problems =
> with periodic broadcasts.

You can't win.   You can only increase the reliability level.   Router
outages are (I suspect) uncommon compared to DHCP server outages, at
least in situations where DHCP service is being provided across the
router.   The likelihood that both would happen at the same time is
small - normally servers take longer to recover after a power failure
than routers - so I really don't think this is a big problem,
certainly not one that would justify broadcasts to the entire set of
networks a DHCP server supports more frequently than a client would
retry.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Mon Sep 25 20:19:05 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18160;
	Mon, 25 Sep 2000 20:19:04 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8Q0Idb20140;
	Mon, 25 Sep 2000 20:18:39 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8Q0IQb25262
	for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 20:18:26 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-253.ip.theriver.com [206.97.58.253]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id NAA08350 for <dhcp-v6@bucknell.edu>; Sun, 24 Sep 2000 13:42:54 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8Q0Gcp07419 for <dhcp-v6@bucknell.edu>; Mon, 25 Sep 2000 17:16:38 -0700 (MST)
Message-Id: <200009260016.e8Q0Gcp07419@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Mon, 25 Sep 2000 19:47:43 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC1A9@lespaul.process.com> 
Date: Mon, 25 Sep 2000 17:16:38 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> The only benefit from sending the list in the RENEWING case is the
> case where the server has lost stable storage.

Realistically, I don't think this is a problem significant enough to
be worth trying to solve - this is a fairly unlikely event.  Also, if
the server loses stable storage, it would be sheer luck if any given
client were able to get back its old set of addresses before some
other client got it, even if we did insist that clients always send
back all their addresses in every renewal request.   So it's a pretty
high price to pay for a pretty low return.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Tue Sep 26 01:39:18 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28207;
	Tue, 26 Sep 2000 01:39:18 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8Q5ZVb32088;
	Tue, 26 Sep 2000 01:35:31 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8Q5ZHb16894
	for <dhcp-v6@bucknell.edu>; Tue, 26 Sep 2000 01:35:18 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 88DD23040; Tue, 26 Sep 2000 00:35:02 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id BAB1830A5
	for <dhcp-v6@bucknell.edu>; Tue, 26 Sep 2000 00:35:01 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id BAA0000806480; Tue, 26 Sep 2000 01:34:14 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009260534.BAA0000806480@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Mon, 25 Sep 2000 13:59:54 PDT."
             <200009252059.e8PKxsp04814@grosse.bisbee.fugue.com> 
Date: Tue, 26 Sep 2000 01:33:52 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>> So the client in the present spec does not have an IA to renew but we
>> did put in how to retransmit a request and I think we will have to do
>> the same with an IA.  

>Right, but what happens if the DHCP server the client contacted
>previously is down when it tries to renew?   It can retry all it
>wants, but it won't get a response.   Does it just time out and let
>its connections die, or does it try to contact any other DHCP server
>that may be present on the wire to see if it can get that DHCP server
>to renew the IA with the same addresses?

This was one of our questions in Pittsburgh we did not get to.   What we
had previously was that the client would go back to solicit.  But in the
current draft we did a lot of work to make the client be able to talk
with multiple servers.  So we left it blank in the spec for discussion.
The reason is in the current draft the client could specifically keep
server advertisements for later purposes possibly at lower preference
value than the server that was chosen for the requst. So we were not
sure what consensus was and it was TBD as we know the WG wanted more
than we had done thus far and going back to solicit would not be needd
if the client had another server address.

>This is the equivalent of the transition between RENEWING and
>REBINDING in DHCPv4.   I don't see anything like that in the current
>draft.   Is this omission intentional?

Yes it was.  Note we also had the R bit in the Request if the client 
rebooted which would signal a rebind too.  But thats a hack and we need to 
fix that this time around with the IA strategy.

But I am thinking with the IA and your model dhcpv6  would even be more
idempotent than now with respect to REBIND or RENEW.  A clear advantage
of your model.

But we should nail down this time if the REQUEST Fails what to do?

I think we should permit clients to use other server if known but report
error to console and log (with out getting into implementation details)
and if it don't have a server then begin SOLICIT if that fails then
there is a network problem.  

At the server the same addresses and lease will exist for that IA.
Hence, the server just sends the addresses again.  Because we have
changed the model for addresses from what it is at the server its static
and won't matter.  This fixes the bug we had in dhcpv6 current draft
IMO.  Also pretty easy to implement.

Well it might be to strong to say bug above but it certainly removes a
whole bunch of complexity with the IA model or really the new address 
model.  We still need to figure out what exactly is the IA?

p.s. In New Jersey for IPv6 customer that has requested person who 
knows how to implement IPv6. I am in Red Roof Inn typing this.  I won't see
mail till tomorrow night or early wednesday.

regards,
/jim

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Tue Sep 26 06:19:50 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08394;
	Tue, 26 Sep 2000 06:19:49 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8QAHHb14031;
	Tue, 26 Sep 2000 06:17:17 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:root@hygro.adsl.duke.edu [152.16.64.159])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8QAHEb06727
	for <dhcp-v6@bucknell.edu>; Tue, 26 Sep 2000 06:17:14 -0400 (EDT)
Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1])
	by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id GAA02068
	for <dhcp-v6@bucknell.edu>; Tue, 26 Sep 2000 06:16:44 -0400
Message-Id: <200009261016.GAA02068@hygro.adsl.duke.edu>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Mon, 25 Sep 2000 16:02:26 EDT." <200009252002.QAA0000713658@anw.zk3.dec.com> 
Date: Tue, 26 Sep 2000 06:16:44 -0400
From: Thomas Narten <narten@RALEIGH.IBM.COM>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hi Jim,

> Its also in 11.4.2 section under Request Retransmit.  The current specs
> version of an IA is the link-local address + prefix for that link.  The
> client does not try to renew the IA as the concept is new from our
> design discussions.  The spec was written with the intention that
> link-local and prefix of link will be unique and it is in IPv6, except
> when a node changes its link-local now because of privacy concerns and
> uses anonymous addresses.

To clarify, in the current version of anonymous addresses
(draft-ietf-ipngwg-addrconf-privacy-03.txt) link-local (and
site-local) addresses do not change and are not made anonymous. Only
global addresses are subject to being anonymized.

Thomas



From owner-dhcp-v6@bucknell.edu  Tue Sep 26 11:33:40 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11164;
	Tue, 26 Sep 2000 11:33:40 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8QFTab02177;
	Tue, 26 Sep 2000 11:29:36 -0400 (EDT)
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8QFTUb06623
	for <dhcp-v6@bucknell.edu>; Tue, 26 Sep 2000 11:29:32 -0400 (EDT)
Received: from eastmail1.East.Sun.COM ([129.148.1.240])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22578
	for <dhcp-v6@bucknell.edu>; Tue, 26 Sep 2000 09:29:29 -0600 (MDT)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA29868
	for <dhcp-v6@bucknell.edu>; Tue, 26 Sep 2000 11:29:27 -0400 (EDT)
Received: from thunk (localhost [127.0.0.1])
	by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e8QFStl108346
	for <dhcp-v6@bucknell.edu>; Tue, 26 Sep 2000 11:28:55 -0400 (EDT)
Message-Id: <200009261528.e8QFStl108346@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@east.sun.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Mon, 25 Sep 2000 17:16:38 PDT."
             <200009260016.e8Q0Gcp07419@grosse.bisbee.fugue.com> 
Reply-to: sommerfeld@east.sun.com
Date: Tue, 26 Sep 2000 11:28:55 -0400
Sender: owner-dhcp-v6@bucknell.edu
X-Sender: sommerfeld@thunk.east.sun.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

> Also, if the server loses stable storage, it would be sheer luck if
> any given client were able to get back its old set of addresses
> before some other client got it

Given the size of the v6 address space and the standard subnet size,
I'd say that the probabilities are (or could be engineered to be) on
the side of non-reuse.

				- Bill



From owner-dhcp-v6@bucknell.edu  Tue Sep 26 12:37:16 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12028;
	Tue, 26 Sep 2000 12:37:16 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8QGYJb27554;
	Tue, 26 Sep 2000 12:34:19 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8QGY5b23009
	for <dhcp-v6@bucknell.edu>; Tue, 26 Sep 2000 12:34:05 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-141.ip.theriver.com [206.97.58.141]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id FAA12218; Mon, 25 Sep 2000 05:58:29 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8QGVUA00806; Tue, 26 Sep 2000 09:31:31 -0700 (MST)
Message-Id: <200009261631.e8QGVUA00806@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
cc: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bill Sommerfeld <sommerfeld@east.sun.com> 
   of "Tue, 26 Sep 2000 11:28:55 -0400." <200009261528.e8QFStl108346@thunk.east.sun.com> 
Date: Tue, 26 Sep 2000 09:31:30 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Given the size of the v6 address space and the standard subnet size,
> I'd say that the probabilities are (or could be engineered to be) on
> the side of non-reuse.

Yup.   Sounds like stateless addrconf.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Tue Sep 26 12:56:11 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12432;
	Tue, 26 Sep 2000 12:56:10 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8QGtmb20716;
	Tue, 26 Sep 2000 12:55:48 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8QGtYb24027
	for <dhcp-v6@bucknell.edu>; Tue, 26 Sep 2000 12:55:34 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8N3JF>; Tue, 26 Sep 2000 12:55:19 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC1B4@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Tue, 26 Sep 2000 12:55:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

In fact, with duplicate address detection and the huge address space, a
server maybe could even chose to not store any information about a client.
If the addresses are assigned by incrementing a counter or some such
mechansim, it would not need to really remember (except of course if we
didn't send the addresses in the RENEWAL request in which case it must).

I'm not arguing for server implemnetations to do this or even be allowed to
do it.

And this would really be more of the stateless addrconf instead of stateful
- except of course that a server could have a list of "allowed" clients and
only respond with addresses to those clients that were in that list.

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Tuesday, September 26, 2000 12:32 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...



> Given the size of the v6 address space and the standard subnet size,
> I'd say that the probabilities are (or could be engineered to be) on
> the side of non-reuse.

Yup.   Sounds like stateless addrconf.

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Wed Sep 27 17:09:12 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22593
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 27 Sep 2000 17:09:12 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8RL4Gb25935;
	Wed, 27 Sep 2000 17:04:16 -0400 (EDT)
Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8RL49b04747
	for <dhcp-v4@bucknell.edu>; Wed, 27 Sep 2000 17:04:09 -0400 (EDT)
Received: from HALVESTR-8KCDT.maxware.no (ams-vpdn-client-342.cisco.com [144.254.47.90])
	by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id XAA21797;
	Wed, 27 Sep 2000 23:04:01 +0200
Message-Id: <4.3.2.7.2.20000927153825.029d7c00@127.0.0.1>
X-Sender: hta@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 27 Sep 2000 15:40:10 +0200
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Harald Alvestrand <Harald@Alvestrand.no>
Subject: Re: DHCP server startup announcement 
Cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
In-Reply-To: <200009251939.e8PJdsp03763@grosse.bisbee.fugue.com>
References: <Message from Nathan Lane <ndlane@wal-mart.com>
 <D3EA66988D05D411BFFB00A0C9899382468221@honts333.homeoffice.wal-mart.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: Harald@Alvestrand.no
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 12:39 25/09/2000 -0700, Ted Lemon wrote:
>Nope.   If the server is up when the client comes up, the client will
>discover it.  It's only if the server _isn't_ up when the client
>starts that the client needs to get this message.

I had trouble once with a DHCP server that handed out very long term 
leases, and lost its memory when rebooted, handing out the same numbers 
again to new clients.
If a FORCERENEW command had been available, the vendor could have had an 
alternative to using nonvolatile storage.

          Harald

--
Harald Tveit Alvestrand, alvestrand@cisco.com
+47 41 44 29 94
Personal email: Harald@Alvestrand.no



From owner-dhcp-v4@bucknell.edu  Wed Sep 27 18:02:00 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23241
	for <DHC-ARCHIVE@odin.ietf.org>; Wed, 27 Sep 2000 18:02:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8RLweb11668;
	Wed, 27 Sep 2000 17:58:40 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8RLwcb01770
	for <dhcp-v4@bucknell.edu>; Wed, 27 Sep 2000 17:58:38 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (206-97-58-118.ip.theriver.com [206.97.58.118]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id LAA18101; Tue, 26 Sep 2000 11:23:04 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8RLseg04296; Wed, 27 Sep 2000 14:54:42 -0700 (MST)
Message-Id: <200009272154.e8RLseg04296@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP server startup announcement 
In-Reply-To: Message from Harald Alvestrand <Harald@Alvestrand.no> 
   of "Wed, 27 Sep 2000 15:40:10 +0200." <4.3.2.7.2.20000927153825.029d7c00@127.0.0.1> 
Date: Wed, 27 Sep 2000 14:54:40 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> If a FORCERENEW command had been available, the vendor could have had an 
> alternative to using nonvolatile storage.

> I had trouble once with a DHCP server that handed out very long term 
> leases, and lost its memory when rebooted, handing out the same numbers 
> again to new clients.
> If a FORCERENEW command had been available, the vendor could have had an 
> alternative to using nonvolatile storage.

Understood.   But how would you deal with the problem of a network
outage at the time that you decided to recover from this using
DHCPFORCERENEW?   Broadcast the DHCPFORCERENEW every five seconds?
Also, what's being proposed here is a DHCPFORCERENEW that would cause
clients *without* existing DHCP-assigned addresses to try to get
DHCP-assigned addresses, so this wouldn't help in your case.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Wed Sep 27 22:17:53 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27478;
	Wed, 27 Sep 2000 22:17:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8S299b15085;
	Wed, 27 Sep 2000 22:09:17 -0400 (EDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8S28tb25975
	for <dhcp-v6@bucknell.edu>; Wed, 27 Sep 2000 22:08:55 -0400 (EDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id A5090327C; Wed, 27 Sep 2000 21:08:39 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 22840310A
	for <dhcp-v6@bucknell.edu>; Wed, 27 Sep 2000 21:08:39 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id WAA0000595707; Wed, 27 Sep 2000 22:08:31 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009280208.WAA0000595707@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Tue, 26 Sep 2000 06:16:44 EDT."
             <200009261016.GAA02068@hygro.adsl.duke.edu> 
Date: Wed, 27 Sep 2000 22:08:30 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Hi Thomas,

>> Its also in 11.4.2 section under Request Retransmit.  The current specs
>> version of an IA is the link-local address + prefix for that link.  The
>> client does not try to renew the IA as the concept is new from our
>> design discussions.  The spec was written with the intention that
>> link-local and prefix of link will be unique and it is in IPv6, except
>> when a node changes its link-local now because of privacy concerns and
>> uses anonymous addresses.

>To clarify, in the current version of anonymous addresses
>(draft-ietf-ipngwg-addrconf-privacy-03.txt) link-local (and
>site-local) addresses do not change and are not made anonymous. Only
>global addresses are subject to being anonymized.

Great.  I just assumed the EUID got trashed.  Bad assumption.  Glad you
caught that.

That means we can still use the link-local address if we want as
described in DHCPv6 as potentially part of the IA or at least keep in
the discussion.

thanks
/jim



From owner-dhcp-v6@bucknell.edu  Wed Sep 27 23:57:44 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29836;
	Wed, 27 Sep 2000 23:57:44 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8S3t3b00941;
	Wed, 27 Sep 2000 23:55:03 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8S3skb03489
	for <dhcp-v6@bucknell.edu>; Wed, 27 Sep 2000 23:54:47 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA05446
	for <dhcp-v6@bucknell.edu>; Wed, 27 Sep 2000 20:54:45 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id UAA20589
	for <dhcp-v6@bucknell.edu>; Wed, 27 Sep 2000 20:54:45 -0700 (PDT)
Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18])
	by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8S3she398022
	for <dhcp-v6@bucknell.edu>; Wed, 27 Sep 2000 20:54:43 -0700 (PDT)
Date: Wed, 27 Sep 2000 20:54:37 -0700 (PDT)
From: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Subject: Re: DHCPv6 address model proposal...
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Message-ID: <Roam.SIMC.2.0.6.970113277.11670.nordmark@jurassic>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Ralph,

> My thought was that specifying that the server send a complete list of only 
> the client's currently valid addresses was actually a simplification - the 
> client can simply throw out its old list of addresses and copy down the 
> current list from the server.
> 
> However, there is a second step - the client has to update the 
> configuration of its interfaces with the list of addresses from the 
> server.  So, I imagine simply omitting addresses makes the client's job a 
> little harder - it has to poke around at each of the interfaces and see if 
> any of the addresses on those interfaces were missing from the message and 
> must therefore be un-configured.

Agreed.
This is made a bit tricker by the fact that it should be possible to
use both stateless and DHCPv6 to configure addresses on a host at
the same time (section 4 in RFC 2462).
Thus the client should not touch any IP addresses that were configured 
through the stateful mechanism when doing the above un-configuration.

  Erik

> But, as Ted points out, requiring the server to specifically invalidate 
> addresses may make the server implementation more complex - the server will 
> have to remember each client's previous list of assigned addresses as well 
> as any newly assigned addresses until the client has renewed its IA.
> 
> - Ralph
> 



From owner-dhcp-v6@bucknell.edu  Thu Sep 28 14:33:58 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29083;
	Thu, 28 Sep 2000 14:33:57 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8SITkb19643;
	Thu, 28 Sep 2000 14:29:46 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8SITbb13639
	for <dhcp-v6@bucknell.edu>; Thu, 28 Sep 2000 14:29:37 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (dhcp-248.rc.vix.com [204.152.187.248]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id HAA22000 for <dhcp-v6@bucknell.edu>; Wed, 27 Sep 2000 07:54:04 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8SIPfE00938 for <dhcp-v6@bucknell.edu>; Thu, 28 Sep 2000 11:25:42 -0700 (MST)
Message-Id: <200009281825.e8SIPfE00938@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Wed, 27 Sep 2000 22:08:30 -0400." <200009280208.WAA0000595707@anw.zk3.dec.com> 
Date: Thu, 28 Sep 2000 11:25:41 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> That means we can still use the link-local address if we want as
> described in DHCPv6 as potentially part of the IA or at least keep in
> the discussion.

The link-local address changes when you swap network cards.  It is
stable with respect to a piece of peripheral hardware, not with
respect to an actual client machine.   For this reason, I am not at
all enthusiastic about the idea of using it as a client identifier.
If we don't strongly discourage its use, I am afraid that we will run
into the same old set of problems we had with DHCPv4 with respect to
client identifiers being tied to hardware.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Thu Sep 28 15:39:01 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00461;
	Thu, 28 Sep 2000 15:39:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8SJa6b24676;
	Thu, 28 Sep 2000 15:36:06 -0400 (EDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8SJa2b10869
	for <dhcp-v6@bucknell.edu>; Thu, 28 Sep 2000 15:36:02 -0400 (EDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id E50AC2039; Thu, 28 Sep 2000 14:35:46 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 7FD961150
	for <dhcp-v6@bucknell.edu>; Thu, 28 Sep 2000 14:35:46 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id PAA0000694326; Thu, 28 Sep 2000 15:35:13 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009281935.PAA0000694326@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Thu, 28 Sep 2000 11:25:41 PDT."
             <200009281825.e8SIPfE00938@grosse.bisbee.fugue.com> 
Date: Thu, 28 Sep 2000 15:35:13 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


>> That means we can still use the link-local address if we want as
>> described in DHCPv6 as potentially part of the IA or at least keep in
>> the discussion.

>The link-local address changes when you swap network cards.  It is
>stable with respect to a piece of peripheral hardware, not with
>respect to an actual client machine.   For this reason, I am not at
>all enthusiastic about the idea of using it as a client identifier.
>If we don't strongly discourage its use, I am afraid that we will run
>into the same old set of problems we had with DHCPv4 with respect to
>client identifiers being tied to hardware.

I hear what your saying.  But I will use an argument you use often I
think?  How many clients of a 1000 node installation will change their
ethernet card within 6 months at Boeing?  Or at MIT?  I would say not
most.  

We are using the link-local address for all kinds of stuff now in IPv6
too.

But how about this strategy.

We clearly are going to change in the packets to having some IA
identifier.  What we can do is permit the link-local address with the
health warning you state above and have other options too.

But here is other idea for the IA to think about.  Organizations can
request a OUI (24bits) and we can then begin to add to that.  I believe
Multicast uses this now.

regards,
/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep 28 16:06:48 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01042;
	Thu, 28 Sep 2000 16:06:46 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8SK6Pb10178;
	Thu, 28 Sep 2000 16:06:25 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8SK6Bb07029
	for <dhcp-v6@bucknell.edu>; Thu, 28 Sep 2000 16:06:11 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NR32>; Thu, 28 Sep 2000 16:05:55 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC1D5@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Thu, 28 Sep 2000 16:05:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

I'm with Ted on this one ... I think it best to attempt to generate a unqiue
client id by not using the link-local or MAC address. At least, the unique
client id should not just be this with a few prefix bytes.

However, having said that, I have no problem in a client generating (with
some random component) a unique client identifier from the MAC address (or
link-local addresses) it may have and saving that in stable storage such
that it would use that in the future, regardless of whether one or more
interfaces is changed.

- Bernie

-----Original Message-----
From: Jim Bound [mailto:bound@zk3.dec.com]
Sent: Thursday, September 28, 2000 3:35 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...



>> That means we can still use the link-local address if we want as
>> described in DHCPv6 as potentially part of the IA or at least keep in
>> the discussion.

>The link-local address changes when you swap network cards.  It is
>stable with respect to a piece of peripheral hardware, not with
>respect to an actual client machine.   For this reason, I am not at
>all enthusiastic about the idea of using it as a client identifier.
>If we don't strongly discourage its use, I am afraid that we will run
>into the same old set of problems we had with DHCPv4 with respect to
>client identifiers being tied to hardware.

I hear what your saying.  But I will use an argument you use often I
think?  How many clients of a 1000 node installation will change their
ethernet card within 6 months at Boeing?  Or at MIT?  I would say not
most.  

We are using the link-local address for all kinds of stuff now in IPv6
too.

But how about this strategy.

We clearly are going to change in the packets to having some IA
identifier.  What we can do is permit the link-local address with the
health warning you state above and have other options too.

But here is other idea for the IA to think about.  Organizations can
request a OUI (24bits) and we can then begin to add to that.  I believe
Multicast uses this now.

regards,
/jim



From owner-dhcp-v4@bucknell.edu  Thu Sep 28 16:30:56 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01476
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 28 Sep 2000 16:30:56 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8SKQVb16261;
	Thu, 28 Sep 2000 16:26:31 -0400 (EDT)
Received: from firewall.agranat.com (agranat.com [198.113.147.2])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8SKQPb13148
	for <dhcp-v4@bucknell.edu>; Thu, 28 Sep 2000 16:26:26 -0400 (EDT)
Received: from agranat.com (alice.agranat.com [192.104.71.130])
	by firewall.agranat.com (8.9.0/8.9.0) with ESMTP id QAA15024
	for <dhcp-v4@bucknell.edu>; Thu, 28 Sep 2000 16:26:09 -0400
Received: (from worley@localhost)
	by agranat.com (8.8.5/8.8.5) id QAA32321;
	Thu, 28 Sep 2000 16:26:08 -0400
Date: Thu, 28 Sep 2000 16:26:08 -0400
Message-Id: <200009282026.QAA32321@agranat.com>
X-Authentication-Warning: alice.agranat.com: worley set sender to worley@alice.agranat.com using -f
From: Dale Worley <worley@agranat.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Server broadcast proposal
Reply-To: worley@agranat.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

There are a number of nagging problems with DHCP that it seems to me
could be solved with a single mechanism -- a message type for a DHCP
server to periodically announce to the clients on its network(s)
certain information (options) that apply to all clients.  Let us call
this message SERVERBROADCAST for the time being.  I am organizing my
thoughts on this subject (perhaps for an Internet Draft) and am
looking for your feedback.

SERVERBROADCAST could be used to solve a number of problems:

- When a DHCP server comes up on a network, to induce changeover from
no-addresses or auto-configured addresses to DHCP-assigned addresses
quickly and more-or-less simultaneously.

- To enable a DHCP server to force clients to give up their current
leases and obtain new leases.

- To enable a DHCP server to announce changes in the lists of network
resources (time servers, print servers, Novell servers, etc.) that are
distributed via various DHCP options.

The main concept is that a DHCP server sends a SERVERBROADCAST message
to all its network(s) when it starts up, and periodically thereafter.
The SERVERBROADCAST message contains options that are apply to all
clients on its network(s).  The DHCP clients listen for and take action
on all options in any received SERVERBROADCAST message.

* Network loading

The intention is that SERVERBROADCAST messages will add very little
load to the network.  The re-sending period should be reasonably long
(1 minute or 5 minutes), and the number of DHCP servers on any network
will be small (typically 3 or less).

In order to prevent the responding clients from flooding the DHCP
server with requests for addresses, it may be a good idea to specify
that they should wait a random (but short) period of time between
receiving a SERVERBROADCAST and acting on it.

* Relaying

SERVERBROADCAST messages should be forwarded to all network(s) that
the DHCP server services.  That is, all the network(s) from which DHCP
requests are forwarded to the server.  In principle, bootp/DHCP relays
should forward SERVERBROADCAST messages in the opposite direction that
they would forward bootp requests.  Of course, this only works on
relays that are updated to do so, but it's hard to see any mechanism
for correctly handling these needs over multiple subnets without
direct support from the relays.

* DHCP Auto-Configuration (option 116)

Option 116 with an argument of 1 specifies that the client should not
use an auto-configured IP address.  When this option is received in a
SERVERBROADCAST message, the client must cease using up any
auto-configured IP address.  (Presumably it then attempts to obtain a
DHCP-assigned address.)

This allows a DHCP server that comes on line to force all the clients on
a network to reconfigure their addresses "at once", reducing the
duration of effective network partitioning due to re-addressing.

* FORCERENEW option to require client to get a new DHCP lease

The FORCERENEW option (as yet unassigned) requires the client to
attempt to renew any DHCP lease that it now has.  If the lease cannot
be renewed, the client must give it up.  (Presumably the client will
then attempt to obtain a new lease.)

(If the server also wishes to force clients to give up auto-configured
addresses, it uses the DHCP Auto-Configuration option as well.)

Since the reception of a SERVERBROADCAST message is non-reliable, the
SERVERBROADCAST FORCERENEW option needs to be re-sent periodically.
In order to permit clients to not respond to each re-send, the
FORCERENEW option needs to contain a "version" identifier.  If the
current lease was issued with the same version identifier, the client
need not renew it.

Since the point of FORCERENEW is to correct the situation where the
server's persistent memory of what leases have been issued has been
lost, the version identifiers cannot be a simple sequence number
(which would itself have to be saved in persistent memory), but rather
needs to be generated by a process like the one used to generate
Universally Unique IDentifiers.  (See draft-leach-uuids-guids-01.txt.)
Thus we probably want to make the version identifiers be 128 bit (16
byte) binary quantities.

This means that when the server issues leases it should provide a
FORCERENEW option giving the version identifier that is currently
being sent in the FORCERENEW option in SERVERBROADCAST messages.

(Presumably leases issued without a FORCERENEW option (the
backward-compatible case) would be defined to have a constant version
identifier, e.g., 0x00000000000000000000001.  Thus if a new-style DHCP
server suddenly comes on line, FORCERENEW will invalidate all the old
leases.)

* Resources

A number of options provide information to the DHCP client about
clients that provide various services.  Some examples are:

   14      Merit Dump File   N          Client to dump and name
                                        the file to dump it to
   15      Domain Name       N          The DNS domain name of the 
                                        client
   41      NIS Servers       N          NIS Server Addresses
   42      NTP Servers       N          NTP Server Addresses
   44      NETBIOS Name Srv  N          NETBIOS Name Servers
   48      X Window Font     N          X Window Font Server
   49      X Window Manager  N          X Window Display Manager
   69      SMTP-Server       N          Simple Mail Server Addresses
   70      POP3-Server       N          Post Office Server Addresses
   71      NNTP-Server       N          Network News Server Addresses
   72      WWW-Server        N          WWW Server Addresses
   73      Finger-Server     N          Finger Server Addresses
   74      IRC-Server        N          Chat Server Addresses
   75      StreetTalk-Server N          StreetTalk Server Addresses
   76      STDA-Server       N          ST Directory Assistance Addresses
   78      Directory Agent   N          directory agent information
   85      NDS Servers       N          Novell Directory Services
   112	   Netinfo Address   N		NetInfo Parent Server Address

Now that it is not uncommon for client systems to remain up for a year
or more, it would be good if there was a method for the server to
actively update this information that it provides to the clients.

Including these options in a SERVERBROADCAST message is a way to do
this.


Dale
-- 
Dale R. WORLEY    Project Manager - UPnP        <dworley@virata.com>
Virata Corp.	  Applications Infrastructure   http://emweb.com



From owner-dhcp-v4@bucknell.edu  Thu Sep 28 16:57:15 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02027
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 28 Sep 2000 16:57:14 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8SKtYb17316;
	Thu, 28 Sep 2000 16:55:34 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8SKtVb22786
	for <dhcp-v4@bucknell.edu>; Thu, 28 Sep 2000 16:55:31 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NRQ8>; Thu, 28 Sep 2000 16:55:16 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC1D7@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: Server broadcast proposal
Date: Thu, 28 Sep 2000 16:55:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: Volz@ipworks.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Dale:

I do think you'll need to consider some issues here that are important and
potentially impact the usefulness of this:

1) Security. Preventing denial of service attacks by changing information
regarding critical resources.

2) Multiple servers with potentially different configuration information -
which server should a client listen to, should it take whatever it receives
(therefore potentially causing a switching of this infomation between
several possible values should different servers be advertisig different
information).

And, in general just to deal with the multiple server issue since this
increases the broadcast traffic with each server added and thus also the
processing burden on all clients.

Note also that we'd need to review the implications to the FAILOVER
protocol. For example, if failover partners are in "NORMAL" state
(communicating), it might be reasonable to assign only ONE the
responsibility of doing periodic broadcasts. However, that might also have
client implications (since clients don't necessarily know the addresses of
both servers and hence may behave differently in certain instances).

3) Impact on existing clients. The DHC WG has been VERY careful (overly so
in my opinion) about making such changes. What will happen to today's
clients that receive these broadcasts? How can you assure they won't cause
problems for existing implementations?

4) Relaying. Relays are not necessarily connected to the same physical
network segment as the DHCP servers. Therefore, how does the DHCP Server
inform the relays. This could be potentially solved by directed broadcasts
to all configured subnets within the server, but that also opens up
potential issues (since directed broadcasts are often considered a security
threat and disabled).

There are likely other issues that will be raised by WG members. These are
the ones that come to (my) mind immediately.

- Bernie

-----Original Message-----
From: Dale Worley [mailto:worley@agranat.com]
Sent: Thursday, September 28, 2000 4:26 PM
To: DHCPv4 discussion list
Subject: Server broadcast proposal


There are a number of nagging problems with DHCP that it seems to me
could be solved with a single mechanism -- a message type for a DHCP
server to periodically announce to the clients on its network(s)
certain information (options) that apply to all clients.  Let us call
this message SERVERBROADCAST for the time being.  I am organizing my
thoughts on this subject (perhaps for an Internet Draft) and am
looking for your feedback.

SERVERBROADCAST could be used to solve a number of problems:

- When a DHCP server comes up on a network, to induce changeover from
no-addresses or auto-configured addresses to DHCP-assigned addresses
quickly and more-or-less simultaneously.

- To enable a DHCP server to force clients to give up their current
leases and obtain new leases.

- To enable a DHCP server to announce changes in the lists of network
resources (time servers, print servers, Novell servers, etc.) that are
distributed via various DHCP options.

The main concept is that a DHCP server sends a SERVERBROADCAST message
to all its network(s) when it starts up, and periodically thereafter.
The SERVERBROADCAST message contains options that are apply to all
clients on its network(s).  The DHCP clients listen for and take action
on all options in any received SERVERBROADCAST message.

* Network loading

The intention is that SERVERBROADCAST messages will add very little
load to the network.  The re-sending period should be reasonably long
(1 minute or 5 minutes), and the number of DHCP servers on any network
will be small (typically 3 or less).

In order to prevent the responding clients from flooding the DHCP
server with requests for addresses, it may be a good idea to specify
that they should wait a random (but short) period of time between
receiving a SERVERBROADCAST and acting on it.

* Relaying

SERVERBROADCAST messages should be forwarded to all network(s) that
the DHCP server services.  That is, all the network(s) from which DHCP
requests are forwarded to the server.  In principle, bootp/DHCP relays
should forward SERVERBROADCAST messages in the opposite direction that
they would forward bootp requests.  Of course, this only works on
relays that are updated to do so, but it's hard to see any mechanism
for correctly handling these needs over multiple subnets without
direct support from the relays.

* DHCP Auto-Configuration (option 116)

Option 116 with an argument of 1 specifies that the client should not
use an auto-configured IP address.  When this option is received in a
SERVERBROADCAST message, the client must cease using up any
auto-configured IP address.  (Presumably it then attempts to obtain a
DHCP-assigned address.)

This allows a DHCP server that comes on line to force all the clients on
a network to reconfigure their addresses "at once", reducing the
duration of effective network partitioning due to re-addressing.

* FORCERENEW option to require client to get a new DHCP lease

The FORCERENEW option (as yet unassigned) requires the client to
attempt to renew any DHCP lease that it now has.  If the lease cannot
be renewed, the client must give it up.  (Presumably the client will
then attempt to obtain a new lease.)

(If the server also wishes to force clients to give up auto-configured
addresses, it uses the DHCP Auto-Configuration option as well.)

Since the reception of a SERVERBROADCAST message is non-reliable, the
SERVERBROADCAST FORCERENEW option needs to be re-sent periodically.
In order to permit clients to not respond to each re-send, the
FORCERENEW option needs to contain a "version" identifier.  If the
current lease was issued with the same version identifier, the client
need not renew it.

Since the point of FORCERENEW is to correct the situation where the
server's persistent memory of what leases have been issued has been
lost, the version identifiers cannot be a simple sequence number
(which would itself have to be saved in persistent memory), but rather
needs to be generated by a process like the one used to generate
Universally Unique IDentifiers.  (See draft-leach-uuids-guids-01.txt.)
Thus we probably want to make the version identifiers be 128 bit (16
byte) binary quantities.

This means that when the server issues leases it should provide a
FORCERENEW option giving the version identifier that is currently
being sent in the FORCERENEW option in SERVERBROADCAST messages.

(Presumably leases issued without a FORCERENEW option (the
backward-compatible case) would be defined to have a constant version
identifier, e.g., 0x00000000000000000000001.  Thus if a new-style DHCP
server suddenly comes on line, FORCERENEW will invalidate all the old
leases.)

* Resources

A number of options provide information to the DHCP client about
clients that provide various services.  Some examples are:

   14      Merit Dump File   N          Client to dump and name
                                        the file to dump it to
   15      Domain Name       N          The DNS domain name of the 
                                        client
   41      NIS Servers       N          NIS Server Addresses
   42      NTP Servers       N          NTP Server Addresses
   44      NETBIOS Name Srv  N          NETBIOS Name Servers
   48      X Window Font     N          X Window Font Server
   49      X Window Manager  N          X Window Display Manager
   69      SMTP-Server       N          Simple Mail Server Addresses
   70      POP3-Server       N          Post Office Server Addresses
   71      NNTP-Server       N          Network News Server Addresses
   72      WWW-Server        N          WWW Server Addresses
   73      Finger-Server     N          Finger Server Addresses
   74      IRC-Server        N          Chat Server Addresses
   75      StreetTalk-Server N          StreetTalk Server Addresses
   76      STDA-Server       N          ST Directory Assistance Addresses
   78      Directory Agent   N          directory agent information
   85      NDS Servers       N          Novell Directory Services
   112	   Netinfo Address   N		NetInfo Parent Server Address

Now that it is not uncommon for client systems to remain up for a year
or more, it would be good if there was a method for the server to
actively update this information that it provides to the clients.

Including these options in a SERVERBROADCAST message is a way to do
this.


Dale
-- 
Dale R. WORLEY    Project Manager - UPnP        <dworley@virata.com>
Virata Corp.	  Applications Infrastructure   http://emweb.com



From owner-dhcp-v4@bucknell.edu  Thu Sep 28 17:27:08 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02691
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 28 Sep 2000 17:27:07 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8SLLsb07923;
	Thu, 28 Sep 2000 17:21:54 -0400 (EDT)
Received: from honts308.wal-mart.com (honts308.wal-mart.com [146.132.234.38])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8SLLqb23617
	for <dhcp-v4@bucknell.edu>; Thu, 28 Sep 2000 17:21:52 -0400 (EDT)
Received: from fwnts001-dmz.wal-mart.com ([146.132.238.58]) by honts308.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id TYGJVWZW; Thu, 28 Sep 2000 16:21:36 -0500
Received: from honts386.homeoffice.wal-mart.com by fwnts001-dmz.wal-mart.com
          via smtpd (for mailout.wal-mart.com [146.132.235.35]) with SMTP; 28 Sep 2000 21:21:36 UT
Received: from honts305.homeoffice.wal-mart.com (unverified) by honts386.homeoffice.wal-mart.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc0a8e0871ae4eee4fa22f@honts386.homeoffice.wal-mart.com> for <dhcp-v4@bucknell.edu>;
 Thu, 28 Sep 2000 16:14:05 -0500
Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21)
	id <TVNVLQGB>; Thu, 28 Sep 2000 16:21:36 -0500
Message-ID: <D3EA66988D05D411BFFB00A0C9899382468233@honts333.homeoffice.wal-mart.com>
From: Nathan Lane <ndlane@wal-mart.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: RE: Server broadcast proposal
Date: Thu, 28 Sep 2000 16:21:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Reply-To: ndlane@wal-mart.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


The mentioned issues are all good issues within DHCP.  However, here are
some comments:

Two out of the three issues raised that SERVERBROADCAST would solve can be
solved, to one extent or another, within the confines of the existing
protocol, relay agents, clients, etc.  By implementing a short renew
interval with a long lease time, a fairly fine degree of parameter changing
and IP changing can be accomplished in a short amount of time.  It is agreed
there are clients that don't accept a lower t1 value, but there are also
clients that claim to be DHCP that don't have the concept of unbinding their
IP address at lease end.

One of the biggest issues that I see with SERVERBROADCAST would be mass
numbers of clients all coming in at exactly the same time.  The mechanism
would have to have a backoff or jitter interval to spread the clients out.
By the time all that complexity is added, what is gained over a shorter (but
carefully implemented) renew interval?

>From what I've seen, relay agents are sort of a sacred cow in the WG.  They
are very difficult to modify as they are often not under the control of the
same people that manage DHCP.  

Another issue is security.  It would not only be opening up a large DoS
attack hole, but a more insidious hijacking attack.  There are ways around
this, but the very opening of another port with a listener on it really
raises a number of security concerns.

-Nathan Lane




**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to 
whom they are addressed.  If you have received this email 
in error destroy it immediately.
**********************************************************************



From owner-dhcp-v6@bucknell.edu  Thu Sep 28 18:17:04 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03846;
	Thu, 28 Sep 2000 18:17:03 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8SMEWb28355;
	Thu, 28 Sep 2000 18:14:32 -0400 (EDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8SMELb02460
	for <dhcp-v6@bucknell.edu>; Thu, 28 Sep 2000 18:14:22 -0400 (EDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 9762626DA; Thu, 28 Sep 2000 18:14:06 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP id 72A163301
	for <dhcp-v6@bucknell.edu>; Thu, 28 Sep 2000 18:14:06 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id SAA0000633699; Thu, 28 Sep 2000 18:13:31 -0400 (EDT)
From: Jim Bound <bound@ZK3.DEC.COM>
Message-Id: <200009282213.SAA0000633699@anw.zk3.dec.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Cc: bound@ZK3.DEC.COM
Subject: Re: DHCPv6 address model proposal... 
In-reply-to: Your message of "Thu, 28 Sep 2000 16:05:54 EDT."
             <63D30D6E10CFD11190A90000F805FE8602BEC1D5@lespaul.process.com> 
Date: Thu, 28 Sep 2000 18:13:30 -0400
X-Mts: smtp
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


I am with you and ted too.  

but what I am concerned about is getting a spec solution out by
december too.

not pushing the link-local address but as example.  for the link-local
the dhcp server can trust it is unique on a link and the prefix is
unique on a link.  no chance of duplication because of DAD and address
architecture in IPv6.

How do we verify that a clients IA is in fact unique if it don't verify
that with other clients?
 a) on the link best case
 b) with the servers dhcp domain?

Also what is the range that the IA is unique?
 1) link
 2) site
 3) global (I doubt we can figure that out in dhc)

We need to state how far the IA is unique for a dhcp server

In the current spec that is known.

That is why I brought up the OUI to Ted ????

/jim



From owner-dhcp-v6@bucknell.edu  Thu Sep 28 20:28:54 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05957;
	Thu, 28 Sep 2000 20:28:54 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8T0QGb27880;
	Thu, 28 Sep 2000 20:26:17 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8T0QEb27230
	for <dhcp-v6@bucknell.edu>; Thu, 28 Sep 2000 20:26:15 -0400 (EDT)
Received: from sunmail1.Sun.COM ([129.145.1.2])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA22806
	for <dhcp-v6@bucknell.edu>; Thu, 28 Sep 2000 17:26:13 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166])
	by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id RAA27832
	for <dhcp-v6@bucknell.edu>; Thu, 28 Sep 2000 17:26:13 -0700 (PDT)
Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18])
	by jurassic.eng.sun.com (8.11.1+Sun/8.11.1.Beta1) with SMTP id e8T0QC5545773
	for <dhcp-v6@bucknell.edu>; Thu, 28 Sep 2000 17:26:12 -0700 (PDT)
Date: Thu, 28 Sep 2000 17:26:05 -0700 (PDT)
From: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Reply-To: Erik Nordmark <Erik.Nordmark@ENG.SUN.COM>
Subject: Re: DHCPv6 address model proposal... 
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
In-Reply-To: "Your message with ID" <200009252238.e8PMcep06075@grosse.bisbee.fugue.com>
Message-ID: <Roam.SIMC.2.0.6.970187165.23431.nordmark@jurassic>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


Ted,

> No.  REBIND is when the client has already tried to renew the lease by
> contacting the server from which it got the lease using a unicast
> message.  Time is running out, so it decides to see if it can contact
> another server using multicast (broadcast in the DHCPv4 case).
> REBINDING and RENEWING are two distinct states, and REBINDING is
> specifically for cases where the old server can't be contacted.
> 
> I do not think it is necessary for the client to send an address list
> in the RENEWING case - only in the REBINDING case.

I agree for the purposes that has been currently discussed.

But not too long back we discussed whether the omission
of an address from an IAS when renewing was to be interpreted as
"invalidate any other address not returned by the server".
I might be wrong but I think I saw concensus not to treat a "missing"
address as a directive for the client to invalidate it.

Assuming I didn't miss anything, we have two choices dealing
with the server removing addresses/prefixes from use
(apart from explicit reconfigure of course):
 - the server retains state of all addresses handed to the client
   and when one address is removed from the set the server
   hands that back to the client with valid lifetime = 0
   when the client renews. For reliability the server might need to
   retain information about the invalidated address for some time
   since the client might not receive the first reply that has lifetime = 0.

 - require that the client include all addresses when renewing.
   if the server see one address that shouldn't be part of the set
   the reply will include that address with lifetime = 0.
   Nothing special needs to be done to get reliability here.

I might have missed this being discussed in the past.

   Erik



From owner-dhcp-v6@bucknell.edu  Thu Sep 28 21:49:56 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07575;
	Thu, 28 Sep 2000 21:49:55 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8T1kkb29240;
	Thu, 28 Sep 2000 21:46:46 -0400 (EDT)
Received: from lespaul.process.com (lespaul.process.com [192.42.95.27])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8T1kjb19199
	for <dhcp-v6@bucknell.edu>; Thu, 28 Sep 2000 21:46:45 -0400 (EDT)
Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21)
	id <TBG8NRXG>; Thu, 28 Sep 2000 21:46:29 -0400
Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEC1DA@lespaul.process.com>
From: Bernie Volz <Volz@ipworks.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: RE: DHCPv6 address model proposal...
Date: Thu, 28 Sep 2000 21:46:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

> - the server retains state of all addresses handed to the client
>   and when one address is removed from the set the server
>   hands that back to the client with valid lifetime = 0
>   when the client renews. For reliability the server might need to
>   retain information about the invalidated address for some time
>   since the client might not receive the first reply that has lifetime =
0.

The server need not do this. The server can simply eliminate the address
from the client's set. The client can continue to use that address until the
lifetimes "expire" - just because it isn't in the server's response does not
mean that the address has expired.

Of course, you are correct if the server wants to immediately remove the
address from the client's set.


While I do understand the desire to reduce packet sizes and avoid
unnecessary data in packets, I am a bit uncomfortable with not having the
client supply the addresses. We have discussed this and I agree that in
almost all cases it isn't explicitly necessary. But it is a major shift from
what happens today in DHCPv4 and I just fear it may be a mistake. I also
think it benefits the server since it too can know what the client knows.



-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark@ENG.SUN.COM]
Sent: Thursday, September 28, 2000 8:26 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...



Ted,

> No.  REBIND is when the client has already tried to renew the lease by
> contacting the server from which it got the lease using a unicast
> message.  Time is running out, so it decides to see if it can contact
> another server using multicast (broadcast in the DHCPv4 case).
> REBINDING and RENEWING are two distinct states, and REBINDING is
> specifically for cases where the old server can't be contacted.
> 
> I do not think it is necessary for the client to send an address list
> in the RENEWING case - only in the REBINDING case.

I agree for the purposes that has been currently discussed.

But not too long back we discussed whether the omission
of an address from an IAS when renewing was to be interpreted as
"invalidate any other address not returned by the server".
I might be wrong but I think I saw concensus not to treat a "missing"
address as a directive for the client to invalidate it.

Assuming I didn't miss anything, we have two choices dealing
with the server removing addresses/prefixes from use
(apart from explicit reconfigure of course):
 - the server retains state of all addresses handed to the client
   and when one address is removed from the set the server
   hands that back to the client with valid lifetime = 0
   when the client renews. For reliability the server might need to
   retain information about the invalidated address for some time
   since the client might not receive the first reply that has lifetime = 0.

 - require that the client include all addresses when renewing.
   if the server see one address that shouldn't be part of the set
   the reply will include that address with lifetime = 0.
   Nothing special needs to be done to get reliability here.

I might have missed this being discussed in the past.

   Erik



From owner-dhcp-v4@bucknell.edu  Thu Sep 28 23:19:36 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09544
	for <DHC-ARCHIVE@odin.ietf.org>; Thu, 28 Sep 2000 23:19:35 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8T3G4b12574;
	Thu, 28 Sep 2000 23:16:04 -0400 (EDT)
Received: from srvr20.engin.umich.edu (root@srvr20.engin.umich.edu [141.213.75.22])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8T3Fob17743
	for <dhcp-v4@bucknell.edu>; Thu, 28 Sep 2000 23:15:50 -0400 (EDT)
Received: from ct.engin.umich.edu (root@ct.engin.umich.edu [141.213.40.178])
	by srvr20.engin.umich.edu (8.9.1a/8.9.1) with ESMTP id XAA08309;
	Thu, 28 Sep 2000 23:15:48 -0400 (EDT)
Received: from localhost (hobbes@localhost [127.0.0.1])
	by ct.engin.umich.edu (8.9.1a/8.9.1) with ESMTP id XAA01552;
	Thu, 28 Sep 2000 23:15:47 -0400 (EDT)
Message-Id: <200009290315.XAA01552@ct.engin.umich.edu>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: Server broadcast proposal 
In-reply-to: Your message of Thu, 28 Sep 2000 16:26:08 -0400
Date: Thu, 28 Sep 2000 23:15:47 -0400
From: Steve Mattson <hobbes@engin.umich.edu>
Reply-To: hobbes@engin.umich.edu
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


  Date:    Thu, 28 Sep 2000 16:26:08 -0400
  To:      DHCPv4 discussion list <dhcp-v4@bucknell.edu>
  From:    Dale Worley <worley@agranat.com>
  Subject: Server broadcast proposal
  ...
  - To enable a DHCP server to announce changes in the lists of network
  resources (time servers, print servers, Novell servers, etc.) that are
  distributed via various DHCP options.
  ...
  * Resources
  
  A number of options provide information to the DHCP client about
  clients that provide various services.  Some examples are:
  ...
  Now that it is not uncommon for client systems to remain up for a year
  or more, it would be good if there was a method for the server to
  actively update this information that it provides to the clients.
  
  Including these options in a SERVERBROADCAST message is a way to do
  this.
  
  
  Dale
  -- 
  Dale R. WORLEY    Project Manager - UPnP        <dworley@virata.com>
  Virata Corp.	  Applications Infrastructure   http://emweb.com
  

Our group manages a number of network services for two essentially
separate organizations which have different needs but share the same
facilities and networks.  We run one set of DHCP servers for both
organizations and serve different sets of network configurations 
based on DHCP client affiliations.  The set of common services 
between the two classes of clients is basically limited to 
information about the subnet involved such as netmask.  We would
not be able to effectively load up the SERVERBROASCAST packets
for these networks in response to a server change within one
organization that did not result in a common server set with the
other.

An alternative may be to have the SERVERBROASCAST packets only 
indicate that a change may have taken place on the DHCP server 
end and that the DHCP client should initiate a poll for updated 
configuration information.  This would be similar to a DNS master 
sending out a NOTIFY packet to the slaves it is aware of in the 
sense that the slaves must then initiate the check to see if the 
event on the master was relevant to each slave or not.  

You would also cut down on the size of the packets that DHCP 
clients must repeatedly process.  Broadcasting such a packet 
once a minute per DHCP server per three or so on your network 
doesn't require much processor power on the server end, true.  
Analyzing three packets per minute per how ever many DHCP clients 
you have on your networks, even if only to determine that the 
version number macthes that of the last broadcast you saw from 
that DHCP server, starts to add up after a while.  The broadcast 
packets should be as small as possible.

Steve Mattson
University of Michigan



From owner-dhcp-v4@bucknell.edu  Fri Sep 29 02:06:32 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23995
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 29 Sep 2000 02:06:32 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8T62qb21170;
	Fri, 29 Sep 2000 02:02:52 -0400 (EDT)
Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8T62jb08367
	for <dhcp-v4@bucknell.edu>; Fri, 29 Sep 2000 02:02:45 -0400 (EDT)
Received: from HALVESTR-8KCDT.maxware.no (isdn-nat-1.cisco.com [192.82.152.130])
	by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id IAA06590;
	Fri, 29 Sep 2000 08:02:29 +0200
Message-Id: <4.3.2.7.2.20000928163819.05700210@127.0.0.1>
X-Sender: hta@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 28 Sep 2000 16:46:14 +0200
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
From: Harald Alvestrand <Harald@Alvestrand.no>
Subject: Re: DHCP server startup announcement 
Cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
In-Reply-To: <200009272154.e8RLseg04296@grosse.bisbee.fugue.com>
References: <Message from Harald Alvestrand <Harald@Alvestrand.no>
 <4.3.2.7.2.20000927153825.029d7c00@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: Harald@Alvestrand.no
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

At 14:54 27/09/2000 -0700, Ted Lemon wrote:
> > I had trouble once with a DHCP server that handed out very long term
> > leases, and lost its memory when rebooted, handing out the same numbers
> > again to new clients.
> > If a FORCERENEW command had been available, the vendor could have had an
> > alternative to using nonvolatile storage.
>
>Understood.   But how would you deal with the problem of a network
>outage at the time that you decided to recover from this using
>DHCPFORCERENEW?   Broadcast the DHCPFORCERENEW every five seconds?

argh - yes.
if we want to complexify this thing, DHCPFORCERENEW should have a 
timestamp, saying "all leases from before this timestamp are declared 
invalid", meaning that we could safely rebroadcast it - but this looks like 
a patch upon a kluge upon a bad implementation - forget it; DHCP doesn't 
deal well with server forgetfulness, and fixing that requires more than an 
off-the-top-of-the-head design idea.

>Also, what's being proposed here is a DHCPFORCERENEW that would cause
>clients *without* existing DHCP-assigned addresses to try to get
>DHCP-assigned addresses, so this wouldn't help in your case.

it should then be called YOUCANASKNOW rather than FORCERENEW, since it 
doesn't want to force a renew......

thanks for listening!
--
Harald Tveit Alvestrand, alvestrand@cisco.com
+47 41 44 29 94
Personal email: Harald@Alvestrand.no



From owner-dhcp-v6@bucknell.edu  Fri Sep 29 06:30:47 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25936;
	Fri, 29 Sep 2000 06:30:46 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8TASAb04959;
	Fri, 29 Sep 2000 06:28:10 -0400 (EDT)
Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8TAS9b00155
	for <dhcp-v6@bucknell.edu>; Fri, 29 Sep 2000 06:28:09 -0400 (EDT)
Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132])
	by palrel1.hp.com (Postfix) with ESMTP id 69178120B
	for <dhcp-v6@bucknell.edu>; Fri, 29 Sep 2000 03:28:06 -0700 (PDT)
Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by hpuxsrv.india.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id PAA12947 for <dhcp-v6@bucknell.edu>; Fri, 29 Sep 2000 15:57:00 +0530 (IST)
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <39D46F37.DCFFCFDB@dce.india.hp.com>
Date: Fri, 29 Sep 2000 16:00:17 +0530
From: vijaya bhaskar <vijayak@dce.india.hp.com>
Organization: hp ISO
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.10 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: IP Address Reconfiguration
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: vijayak@india.hp.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit

Hello,

I'm working on dhcp for hp ISO.

In the Internet draft, it is told that releasable resources like ip
address can be reconfigured using Reconfigure-init followed by
Request/Reply . In case, if the ip address for an particular interface
is reconfigured, what will happen to the existing application running on
that ip address. Is these application needed to be restarted ?

waiting for your reply.

Regards,
Vijay.



From owner-dhcp-v6@bucknell.edu  Fri Sep 29 12:38:25 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02634;
	Fri, 29 Sep 2000 12:38:25 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8TGZlb06740;
	Fri, 29 Sep 2000 12:35:47 -0400 (EDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8TGZeb09143
	for <dhcp-v6@bucknell.edu>; Fri, 29 Sep 2000 12:35:40 -0400 (EDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA00469
	for <dhcp-v6@bucknell.edu>; Fri, 29 Sep 2000 09:35:24 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e8TGZMG12226
	for <dhcp-v6@bucknell.edu>; Fri, 29 Sep 2000 09:35:22 -0700
X-Virus-Scanned:  Fri, 29 Sep 2000 09:35:22 -0700 Nokia Silicon Valley Email Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdLQMDcD; Fri, 29 Sep 2000 09:35:18 PDT
Sender: owner-dhcp-v6@bucknell.edu
Message-ID: <39D4C4C7.FFC1D5AC@iprg.nokia.com>
Date: Fri, 29 Sep 2000 09:35:19 -0700
From: "Charles E. Perkins" <charliep@IPRG.NOKIA.COM>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: IP Address Reconfiguration
References: <39D46F37.DCFFCFDB@dce.india.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: dhcp-v6@bucknell.edu
X-Sender: charliep@iprg.nokia.com
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN
Content-Transfer-Encoding: 7bit


Hello Vijay,

The reconfiguration you refer to was designed for network
renumbering and network administrative purposes.  Any network
renumbering would, presumably, be spread over long enough
time so that applications would be able to complete their
work before the expiration of the lifetime for their original
IP addresses.  Of course, you can always make an application
that needs to run for weeks or months and would thus violate
this design criterion, but the hope is that the overall number
of such applications will be vanishingly small.

Regards,
Charlie P.



vijaya bhaskar wrote:
> 
> Hello,
> 
> I'm working on dhcp for hp ISO.
> 
> In the Internet draft, it is told that releasable resources like ip
> address can be reconfigured using Reconfigure-init followed by
> Request/Reply . In case, if the ip address for an particular interface
> is reconfigured, what will happen to the existing application running on
> that ip address. Is these application needed to be restarted ?
> 
> waiting for your reply.
> 
> Regards,
> Vijay.



From owner-dhcp-v4@bucknell.edu  Fri Sep 29 14:05:54 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04299
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 29 Sep 2000 14:05:54 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8TI28b05433;
	Fri, 29 Sep 2000 14:02:08 -0400 (EDT)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8TI1tb23264
	for <dhcp-v4@bucknell.edu>; Fri, 29 Sep 2000 14:01:55 -0400 (EDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA15961 for <dhcp-v4@bucknell.edu>; Fri, 29 Sep 2000 11:01:54 -0700 (MST)]
Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA11432 for <dhcp-v4@bucknell.edu>; Fri, 29 Sep 2000 11:01:54 -0700 (MST)]
Received: from dma.isg.mot.com (cabs2.dma.isg.mot.com [150.21.2.48])
	by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id OAA09322;
	Fri, 29 Sep 2000 14:01:53 -0400 (EDT)
Message-Id: <200009291801.OAA09322@noah.dma.isg.mot.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: dhcp-v4@bucknell.edu, mpatrick@dma.isg.mot.com
Subject: Re: Option 82 and DCI issues 
In-reply-to: Your message of "Fri, 29 Sep 2000 08:15:29 EDT."
             <88256969.0048D1B7.00@hqoutbound.ops.3com.com> 
Date: Fri, 29 Sep 2000 14:01:52 -0400
From: "Michael W. Patrick" <mpatrick@dma.isg.mot.com>
Reply-To: mpatrick@dma.isg.mot.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN

Jack,

You're right, the agent option wording is unclear. I had intended for 
the DHCP agent option to be the last option *before* the 
the 255. I didn't realize that the 255 is called the "End option".
I'm updating the dhcp agent option draft now, so I'll clarify.

Thanx,
mike


>>>>> "Jack" == Jack Fijolek <Jack_Fijolek@3com.com> writes:


> Mike, Yes, 82 does not have "its own end tag". Some vendors take
> that to mean that the packet itself does not need an end tag since
> 82 says it must be the last option added BUT the RFC says the last
> option MUST be the end option...which is it??

> 4.1 Constructing and sending DHCP messages

>    DHCP clients and servers both construct DHCP messages by filling
> in fields in the fixed format section of the message and appending
> tagged data items in the variable length option area.  The options
> area includes first a four-octet 'magic cookie' (which was described
> in section 3), followed by the options.  The last option must always
> be the 'end' option.

> Jack




> "Michael W. Patrick" <mpatrick@dma.isg.mot.com> on 09/29/2000
> 07:52:17 AM

> Sent by: "Michael W. Patrick" <mpatrick@dma.isg.mot.com>


> To: doug@yas.com cc: Jack Fijolek/MW/US/3Com, "Michael.Patrick"
> <Michael_Patrick-LZZ007@email.mot.com> Subject: Re: Option 82 and
> DCI issues



> Of course 82 does not have its own 255 end tag. Who says it does?

> -mike


>>>>> "Doug" == Doug Jones <doug@yas.com> writes:


>>> ---------- From: doug@yas.com[SMTP:DOUG@YAS.COM] Sent: Thursday,
>>> September 28, 2000 6:45:55 PM To: Jack_Fijolek@3com.com;
>>> Michael.Patrick Subject: RE: Option 82 and DCI issues Auto
>>> forwarded by a Rule
>>> 
>> hey jack,

>> i asked rich woundy for some direction, and will be starting on an
>> I-D for an agent suboption for the 4 byte field currently described
>> in the DCI-REQ message.

>> lemme get the meat of what i want to do written.  then i'll get
>> ahold of you about this piece.

>> dj

>> -----Original Message----- From: Jack_Fijolek@3com.com
>> [mailto:Jack_Fijolek@3com.com] Sent: Saturday, September 23, 2000
>> 9:36 AM To: Doug Jones; michael.patrick@motorola.com Subject: RE:
>> Option 82 and DCI issues




>> Doug, Mike, Has the option 82 piece been specified for CCCM devices
>> yet? If not perhaps the relay-agent draft could, at the same time,
>> clarify use of the 255 (end-tag).  The draft says that the relay
>> agent option must be the last in packet, and, that it must not
>> include a 255 suboption. I have seen confusion in DHCP option 82
>> implementations. My interpretation is that option 82 itself does
>> not include an end tag sub-option but every DHCP packet per RFC
>> still must have an end tag on it. Cisco, for example, has
>> implemented that not only does option 82 NOT include a 255 tag, the
>> entire DHCP packet with option 82 appended has no end tag
>> (following all options).  Regards, Jack Fijolek







From owner-dhcp-v6@bucknell.edu  Fri Sep 29 14:43:24 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05053;
	Fri, 29 Sep 2000 14:43:23 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8TIegb27664;
	Fri, 29 Sep 2000 14:40:42 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8TIeRb11760
	for <dhcp-v6@bucknell.edu>; Fri, 29 Sep 2000 14:40:28 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (dhcp-235.rc.vix.com [204.152.187.235]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id IAA26763; Thu, 28 Sep 2000 08:04:51 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8T1ra900266; Thu, 28 Sep 2000 18:53:36 -0700 (MST)
Message-Id: <200009290153.e8T1ra900266@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
cc: bound@ZK3.DEC.COM
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Jim Bound <bound@ZK3.DEC.COM> 
   of "Thu, 28 Sep 2000 18:13:30 -0400." <200009282213.SAA0000633699@anw.zk3.dec.com> 
Date: Thu, 28 Sep 2000 18:53:35 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> How do we verify that a clients IA is in fact unique if it don't verify
> that with other clients?
>  a) on the link best case
>  b) with the servers dhcp domain?

The schemes that have been proposed for coming up with UUIDs
(Universally Unique Identifiers) rely more on reducing the chance of
collision to ridiculously low amounts than they do on any mechanical
process of guaranteeing that the identifier is unique.  I am pretty
sure that Windows has a UUID that is generated this way.   Computers
with serial numbers could use a vendor name plus the serial number.

I think the language in the draft should say something like "DHCP
clients SHOULD use a client identifier that will not vary as a result
of changes in network hardware and will be consistent between network
interfaces.  DHCP clients SHOULD NOT use the link-layer address of a
network interface by itself as a client identifier, but SHOULD instead
use some other identifier that is known to be globally unique - for
example, a combination of the CPU's serial number and manufacturer's
registered domain name.   DHCP clients that have no unique identifier
other than the link-layer address SHOULD combine the link-layer
address of one or more network interfaces, padded with zeros at the
end to a total length of sixteen bytes, with a randomly-generated
four-byte quantity, and compute an MD5 (SHA?) hash over this to
produce a unique identifier, and should store this identifier in
stable storage.   Clients that have no stable storage MUST use the
link-layer address of one of their network interfaces as the client
identifer, and MUST use the same client identifier for all of their
interfaces."

This is rather convoluted, but I think it covers all the possible
cases where one could get into trouble.   The only case where we could
get into trouble is if two clients connected to the same link use the
HASH (pad16 (link-layer-addr) + random4) and wind up producing the
same hash value.   The reason for using the highly-structured formula
for producing the hash is to make this vanishingly unlikely, but I'm
not a crypto-geek, so I may have gotten it wrong.

We could also require the client to identify which of the algorithms
it is using in the first byte of the identifier, which would avoid
stupid collisions due to differing algorithms.

The language should also probably be made more readable - I'd be happy
to do this if people think this is a good set of methods to use to
generate the client identifier.

BTW, I am just talking about how to generate the common per-client
part of the identifier.  We also talked about the client combining its
per-client identifier with an additional per-instance identifier so as
to uniquely identify an address association, so that the client could
have more than one address association - e.g., for application-
specific situations or for clients supporting more than one interface,
or using DHCP to manage a care-of address as well as a home address.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 29 14:47:51 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05115;
	Fri, 29 Sep 2000 14:47:50 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8TIl7b29974;
	Fri, 29 Sep 2000 14:47:07 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8TIl2b13236
	for <dhcp-v6@bucknell.edu>; Fri, 29 Sep 2000 14:47:02 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (dhcp-235.rc.vix.com [204.152.187.235]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id IAA26782; Thu, 28 Sep 2000 08:11:28 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8TIkq601541; Fri, 29 Sep 2000 11:46:52 -0700 (MST)
Message-Id: <200009291846.e8TIkq601541@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
cc: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Erik Nordmark <Erik.Nordmark@ENG.SUN.COM> 
   of "Thu, 28 Sep 2000 17:26:05 MST." <Roam.SIMC.2.0.6.970187165.23431.nordmark@jurassic> 
Date: Fri, 29 Sep 2000 11:46:52 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> Assuming I didn't miss anything, we have two choices dealing
> with the server removing addresses/prefixes from use
> (apart from explicit reconfigure of course):
>  - the server retains state of all addresses handed to the client
>    and when one address is removed from the set the server
>    hands that back to the client with valid lifetime = 0
>    when the client renews. For reliability the server might need to
>    retain information about the invalidated address for some time
>    since the client might not receive the first reply that has lifetime = 0.
> 
>  - require that the client include all addresses when renewing.
>    if the server see one address that shouldn't be part of the set
>    the reply will include that address with lifetime = 0.
>    Nothing special needs to be done to get reliability here.

I think this is a valid summary, and your list of choices is correct.
I think given that the fact of the client receiving an IA that doesn't
contain a still-valid address does not invalidate the address, we have
to do the first of your two choices.   This is why I was arguing
against this.   But I think the reason for doing it this way is
stronger than the reason for doing it the other way, so I'm not
arguing that point anymore.

			       _MelloN_



From owner-dhcp-v6@bucknell.edu  Fri Sep 29 14:50:39 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05146;
	Fri, 29 Sep 2000 14:50:39 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8TInub26940;
	Fri, 29 Sep 2000 14:49:56 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8TInqb19826
	for <dhcp-v6@bucknell.edu>; Fri, 29 Sep 2000 14:49:52 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (dhcp-235.rc.vix.com [204.152.187.235]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id IAA26803 for <dhcp-v6@bucknell.edu>; Thu, 28 Sep 2000 08:14:18 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8TIng601609 for <dhcp-v6@bucknell.edu>; Fri, 29 Sep 2000 11:49:42 -0700 (MST)
Message-Id: <200009291849.e8TIng601609@grosse.bisbee.fugue.com>
To: DHCPv6 discussion list <dhcp-v6@bucknell.edu>
Subject: Re: DHCPv6 address model proposal... 
In-Reply-To: Message from Bernie Volz <Volz@ipworks.com> 
   of "Thu, 28 Sep 2000 21:46:29 -0400." <63D30D6E10CFD11190A90000F805FE8602BEC1DA@lespaul.process.com> 
Date: Fri, 29 Sep 2000 11:49:42 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: dhcp-v6@bucknell.edu
Sender: owner-dhcp-v6@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> While I do understand the desire to reduce packet sizes and avoid
> unnecessary data in packets, I am a bit uncomfortable with not having the
> client supply the addresses. We have discussed this and I agree that in
> almost all cases it isn't explicitly necessary. But it is a major shift from
> what happens today in DHCPv4 and I just fear it may be a mistake. I also
> think it benefits the server since it too can know what the client knows.

Only if we make it mandatory that the client send this.   I don't
think we should.   We are saying that the client should send this
information when it's in the (currently nonexistant) REBINDING state.
However, if we only send it in that state we get a substantial space
savings - clients should never *get* into that state normally.   So I
think it's worth it.   I think you should have a strong reason to
argue otherwise.

			       _MelloN_



From owner-dhcp-v4@bucknell.edu  Fri Sep 29 14:54:09 2000
Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05229
	for <DHC-ARCHIVE@odin.ietf.org>; Fri, 29 Sep 2000 14:54:08 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e8TIqob00120;
	Fri, 29 Sep 2000 14:52:50 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142])
	by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e8TIqib07525
	for <dhcp-v4@bucknell.edu>; Fri, 29 Sep 2000 14:52:44 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (dhcp-235.rc.vix.com [204.152.187.235]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id IAA26811; Thu, 28 Sep 2000 08:17:10 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id e8TIqX601664; Fri, 29 Sep 2000 11:52:34 -0700 (MST)
Message-Id: <200009291852.e8TIqX601664@grosse.bisbee.fugue.com>
To: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
cc: DHCPv4 discussion list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP server startup announcement 
In-Reply-To: Message from Harald Alvestrand <Harald@Alvestrand.no> 
   of "Thu, 28 Sep 2000 16:46:14 +0200." <4.3.2.7.2.20000928163819.05700210@127.0.0.1> 
Date: Fri, 29 Sep 2000 11:52:33 -0700
From: Ted Lemon <mellon@nominum.com>
Reply-To: mellon@nominum.com
Sender: owner-dhcp-v4@bucknell.edu
X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN


> it should then be called YOUCANASKNOW rather than FORCERENEW, since it 
> doesn't want to force a renew......

I can't argue that point.   I'd personally rather we didn't overload
options - perhaps it should be DHCPADVERTISE.   This is sort of
related to Dale's proposal, although I think Dale's proposal goes a
bit too far - his DHCPFORCERENEW with a timestamp would have to be
signed, and signing such a packet for all clients is a hard problem.
DHCPADVERTISE wouldn't have quite the same security implications.

			       _MelloN_