RE: [dhcwg] Clarification necessary

"Bernie Volz (EUD)" <> Fri, 14 September 2001 20:59 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id QAA26389; Fri, 14 Sep 2001 16:59:56 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id QAA11359; Fri, 14 Sep 2001 16:56:56 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id QAA11334 for <>; Fri, 14 Sep 2001 16:56:54 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id QAA26359 for <>; Fri, 14 Sep 2001 16:57:21 -0400 (EDT)
Received: from ( []) by (8.11.3/8.11.3) with ESMTP id f8EKuOQ08316 for <>; Fri, 14 Sep 2001 15:56:24 -0500 (CDT)
Received: from eamrcnt749 ( []) by (8.11.3/8.11.3) with SMTP id f8EKuN319192 for <>; Fri, 14 Sep 2001 15:56:23 -0500 (CDT)
Received: FROM BY eamrcnt749 ; Fri Sep 14 15:56:22 2001 -0500
Received: by with Internet Mail Service (5.5.2653.19) id <P4M0JT5J>; Fri, 14 Sep 2001 15:56:22 -0500
Message-ID: <>
From: "Bernie Volz (EUD)" <>
To: 'Artur Guja' <>,
Subject: RE: [dhcwg] Clarification necessary
Date: Fri, 14 Sep 2001 15:56:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13D5F.B4E04A70"
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

Some of these points were ones I was going to raise. We do need to work out some of the message contents (options) a bit more completely.

Let me try to answer what I think we should do in these situations (prefixed by BV>). See below.

- Bernie Volz

-----Original Message-----
From: Artur Guja []
Sent: Friday, September 14, 2001 3:05 PM
Subject: [dhcwg] Clarification necessary

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?

BV> Yes, I think it should include the DUID. Basically, just as the
BV> client MUST send the DUID in all messages, so must the server in
BV> all "replies".

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

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

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???)

BV> This is one of the areas that I think needs further clarification.
BV> This is also more complicated because there could be some kinds of
BV> errors that need to be reported (either for a specific address or
BV> for an IAID - and there could be multiple of both in a Decline).
BV> I would suggest the server send back an IA ID with no addresses
BV> if the request is accepted. If errors occur, the addresses that
BV> failed would need to be included.
BV> There are more interesting issues as well, such as what about the
BV> T1/T2 times - I would suggest that those are ignored by the client
BV> for a reply to a Decline (or Release). 
BV> One other thought ... we could have the server return IAIDs and
BV> the addresses that were released with 0 lifetimes!

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

BV> I'm not going to get into the more than one address per IA issue
BV> for now (that's been discussed and rehashed enough times). I believe
BV> the text for Solicit is wrong and will be correct - the information
BV> received in the Advertise for the IA should be included (that helps
BV> the server to remember what it Advertised to the client). The client
BV> can NOT ask for a particular number of addresses. It can ask for
BV> addresses. It gets what it gets. If it wants more, it must ask for
BV> "more" by using a new IAID. If it gets more than it wants, it can
BV> keep them or Release those addresses.

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

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 :))))

BV> We're working on it!

dhcwg mailing list