Subject: RE: DHCPv6 address model proposal...

From: Bernie Volz <[email-masked]>
Date: Mon, 25 Sep 2000 14:30:21 -0400

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:[email-masked]]
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: Ted Lemon <[email-masked]>
Date: Mon, 25 Sep 2000 12:36:45 -0700

> 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: Jim Bound <[email-masked]>
Date: Mon, 25 Sep 2000 16:02:26 -0400

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

>in the spec at all about renewal, other than a brief blurb on

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: Ted Lemon <[email-masked]>
Date: Mon, 25 Sep 2000 13:59:54 -0700

> did put in how to retransmit a request and I think we will have to do

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: Jim Bound <[email-masked]>
Date: Tue, 26 Sep 2000 01:33:52 -0400

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

>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: Thomas Narten <[email-masked]>
Date: Tue, 26 Sep 2000 06:16:44 -0400

Hi Jim,

> 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: Jim Bound <[email-masked]>
Date: Wed, 27 Sep 2000 22:08:30 -0400

Hi Thomas,

>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: Ted Lemon <[email-masked]>
Date: Thu, 28 Sep 2000 11:25:41 -0700

> described in DHCPv6 as potentially part of the IA or at least keep in

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: Jim Bound <[email-masked]>
Date: Thu, 28 Sep 2000 15:35:13 -0400

>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