RE: [dhcwg] Clarification necessary

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 [mailto:skybird@3miasto.net]
Sent: Friday, September 14, 2001 3:05 PM
To: dhcwg@ietf.org
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>
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>
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
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 :))))

BV> We're working on it!

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg