Subject: Re: renewal time

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Sep 2000 22:42:23 -0700

> 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: Ralph Droms <[email-masked]>
Date: Tue, 19 Sep 2000 06:07:49 -0700

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

---

From: Ralph Droms <[email-masked]>
Date: Tue, 19 Sep 2000 06:39:34 -0700

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: Jim Bound <[email-masked]>
Date: Tue, 19 Sep 2000 11:46:04 -0400

>renewal time to be less than the valid lifetimes of all of the IPv6 

SHould be less than the preferred times.

>any event, the server is authoritative about the set of addresses and 

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: Ralph Droms <[email-masked]>
Date: Tue, 19 Sep 2000 18:32:41 -0700

At 11:46 AM 9/19/00 -0400, Jim Bound wrote:
>It makes most sense for the

Agreed...

> >In
>zero valid lifetimes with Router Advertisement.

This DOS attack would come from a malicious server?

>Also if a server does

Yes.

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Wed, 20 Sep 2000 12:40:47 -0400

>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: Erik Nordmark <[email-masked]>
Date: Wed, 20 Sep 2000 20:34:38 -0700 (PDT)

Ralph,

> [...]

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.

> any event, the server is authoritative about the set of addresses and 

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Sep 2000 00:04:55 -0700

> invalidating an address by including it with a zero valid and preferred

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: Ralph Droms <[email-masked]>
Date: Thu, 21 Sep 2000 15:59:08 -0400

>invalidating an address by including it with a zero valid and preferred

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: Ralph Droms <[email-masked]>
Date: Thu, 21 Sep 2000 16:03:32 -0400

At 08:34 PM 9/20/00 -0700, Erik Nordmark wrote:
>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: Ted Lemon <[email-masked]>
Date: Thu, 21 Sep 2000 13:18:25 -0700

> So, I imagine simply omitting addresses makes the client's job a 

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: Ted Lemon <[email-masked]>
Date: Thu, 21 Sep 2000 13:22:40 -0700

> 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: Ralph Droms <[email-masked]>
Date: Thu, 21 Sep 2000 17:01:16 -0400

>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: Thomas Narten <[email-masked]>
Date: Fri, 22 Sep 2000 08:16:42 -0400

Ralph,

> any event, the server is authoritative about the set of addresses and 

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: Ted Lemon <[email-masked]>
Date: Fri, 22 Sep 2000 10:43:24 -0700

> 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.

> 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: Ralph Droms <[email-masked]>
Date: Fri, 22 Sep 2000 15:57:55 -0400

At 08:16 AM 9/22/00 -0400, Thomas Narten wrote:

>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.

>addresses.

Agreed...

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Fri, 22 Sep 2000 23:44:44 -0400

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: Ted Lemon <[email-masked]>
Date: Fri, 22 Sep 2000 21:24:04 -0700

> The complexity to do this is to mirror the addrconf paradigm

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: Jim Bound <[email-masked]>
Date: Sat, 23 Sep 2000 01:02:43 -0400

>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: Ted Lemon <[email-masked]>
Date: Fri, 22 Sep 2000 22:37:03 -0700

> 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: Jim Bound <[email-masked]>
Date: Sun, 24 Sep 2000 23:24:40 -0400

>right?   So what does this have to do with stateless address

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: Jim Bound <[email-masked]>
Date: Sun, 24 Sep 2000 23:56:18 -0400

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: Thomas Narten <[email-masked]>
Date: Mon, 25 Sep 2000 07:35:28 -0400

> 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: Erik Nordmark <[email-masked]>
Date: Thu, 21 Sep 2000 13:02:21 -0700 (PDT)

> the server, which now has to track the administrative removal of

Got it. Thanks.

  Erik

---

From: Ralph Droms <[email-masked]>
Date: Mon, 25 Sep 2000 12:14:40 -0400

Tomas - in general I see your point.  In the particular case you cite:

>learned that address via stateless addrconf, and shouldn't invalidate

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: Ted Lemon <[email-masked]>
Date: Mon, 25 Sep 2000 09:18:47 -0700

> 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: Ted Lemon <[email-masked]>
Date: Mon, 25 Sep 2000 09:32:07 -0700

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: Jim Bound <[email-masked]>
Date: Mon, 25 Sep 2000 12:43:38 -0400

>protocol should not cause a client to drop an address when it doesn't

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. 

>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_