Subject: [dhcwg] Clarification necessary

From: Artur Guja <[email-masked]>
Date: Fri, 14 Sep 2001 21:05:10 +0200

Hello listees,

There are several points in the DHCPv6 draft than I feel need
clarification in further drafts.
I understand that some of it may seem clear to you, some of it may
have already been discussed. Nevertheless I would appreciate maybe
just a little note on EACH of htese points.

1) Does the server include DUID option in ADVERTISE or REPLY?

2) Should the client save its leases to a file or do they just go to
the memory? IOW, are they lost upon reboot?

3) What is the server's reply to a DECLINE? Is there none, or is it a
REPLY message? What is in such a REPLY? (New leases or empty IAs???)

4) Why should there be more than one address assigned to an IA? If so,
how can a client indicate it wants more than one address? (The IAs
have to be empty in SOLICIT).

I'm currently working on an actual implemtation of DHCPv6 for my
diploma at the TUG (Technical Univ of Gdansk). I'd appreciate any
help.

Thanks in advance,
Artur G.

PS: The best help would be to get DHCPv6 to a FINAL standard ASAP, so
that I could be sure what to write :))))

_______________________________________________
dhcwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 17 Sep 2001 17:05:13 -0500

Hi:

As Artur already mentioned, when a node restarts it would likely assume it is perhaps no longer connected to the same link and take steps to "confirm" its addresses by multicasting the Confirm message. Server(s) will respond to this with an indication that the addresses are unacceptable (likely based on the prefixes) or acceptable (again based on the prefixes or because the server assigned those addresses). There may be several different levels of indications in each case - since a server that didn't assign the address might only be able to base its response on the prefixes and not the actual addresses.

A server that receives the Confirm and has a (perhaps "timed-out") Reconfigure-Init needed flag for that client (based on DUID) SHOULD then take steps to initiate the Reconfigure-Init.

My own personal view is that Confirm should not be used to assign new addresses or adjust lifetimes (or even T1/T2 renewal times). It should simply be used to confirm the validity of the addresses on that link. But I'm not sure that is WG consensus.

- Bernie Volz

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Monday, September 17, 2001 3:20 PM
To: Bernie Volz (EUD)
Cc: 'Artur Guja'; [email-masked]
Subject: RE: [dhcwg] Clarification necessary

> BV> A client SHOULD save them such that they survive reboots. This
> BV> is what many DHCPv4 clients already do so it really shouldn't be
> BV> such a big deal. Some of the revised text we're working on will
> BV> provide more clarification around this in cases where a client
> BV> has no permanent storage capabilities. Basically, an ADVERTISE
> BV> will be able to include other IAs for the client that the server
> BV> knows about and it is recommended that these types of clients
> BV> always use the same IA ID (such as 0).

Hmm, has there been any discussion what impact this will have on reconfigure
to do renumbering? I guess the same issue appears with DHCPv4 and its
new ability to do reconfigure.

At a minimum it might make sense to document that reconfigure might not
be able to reach nodes that are turned off but that those nodes
might retain the leases in stable storage.

  Erik