Subject: questions on DHCPv6 -18 rev of draft

From: Vijay Bhaskar A K <[email-masked]>
Date: Tue, 13 Mar 2001 05:35:48 +0530

Hi,
I have few questions regarding the -18 rev of DHCPv6 draft. I will be
attending the design telecon. let me know your comments about these
issues.
Regrads,
Vijay

questions
---------

* Since, in IPv6 routers won't handle the fragmentation. so, DHCPv6 
implmentation has to take care of the fragmentation. 
Assume the client has fragmented the packet in to two packets. The
server will 
read the first packet correctly, since it is in proper packet format. 
Then, the second packet will be discarded, since it has only the
remaining 
content of the previously sent packet.
This is because, the server doesn't know that whether the packet
recieved is 
correct one or the later part of the  prviously sent fragmented packet.
Do we need to have an additional message type (or) a field speciying the
"next fragment" for transmission of the fragemented packet?

* How DUID is generated? what is its format?

* I think we don't need site scoped "All DHCP Clients" multicast address
for sending reconfigure messages. Since, renumbering of network takes
place per link basis. This means we need to send Reconfigure message to
only the nodes in a particular link, not to all the nodes in the site.
Thus, if we use All DHCP clients multicast address, most of the nodes
will unecessarily receive the Reconfigure-init  message. 

* There are some list of Generic Error values like
AuthFailed,PoorlyFormed etc. are defined. But no where it is mentioned
how to return this error value. We need an option or a field for
returning these generic error values. This option must be included in
the base-spec.

* In solicit message, does the client need to send the number of IP
address needed for the IA, in the IA option? I think it is better to
send the requested number of IP address in the Ia option. If the client
is asking "n" number of IP address and the server can offer only "m"
IP-addresses (m<n), then the client can choose better server offering
"n" IP address. This can become one criteria for selecting the server to
send the DHCP Request message.

>The server MUST include options to Advertise message containing any address >that would be assigned to IAs contained in the Solicit message format. 

1. Is this similar to the DHCP OFFER in DHCPv4?
2. If the client has asked "n" IP address, does the server need to send
"n" address in the IA? (or) need to send the just the prefix?
3. If the server does not have one or few of the requested configuration
parameters asked by the client in ORO option, does the server need to
send the only the configuration parameters it have and leave the other
options. (or) since it doesn't have some of the configuration
parameters, will it tollaly ignore the Solicit and don't send reply?
4. If the server can offer only few IP-address (m) less than the
requested number of IP-address (n), does the server needs to respond
with the available number of IP-address (OR) doesn't send Advertise?
5. If the server is sending the "n" IP Addresses in IA option in
Advertise message, it means that, these addresses should not be assigned
to the other clients and is reserved for the client that has sent the
Solicit? 

Request message
_______________

1. assume, the client has asked 2 IP address first time. After some
times, it needs another 3 IP-address in the same interface. This time,
does it need to send a fresh empty IA? or it can ask for another 3
IP-address in the same IA?

a) If it has to send the fresh empty IA, how will the server maintain
the record of these IAs, since the IA sent at the first time and sent
next time will have the same DUID and subnet-prefix. Will the server
treat these two as different or same IAs?

b) why empty IA is to be sent for requesting IP address?

c) what does exactly the empty IA mean? In other words, what are the
fields to be filled in IA options for sending the empty IA.

(eg):- If the client is requesting 3 IP-address,
I think these are fields which must be filled.
(1) option-code
(2) option-len
(3) IA-DUID
(4) num-addrs = 3 

do the addr status, prefix length, IPv6 address, pref life time, val
life time should be present or filled with zeros?

2. If the client has sufficient scope to reach the server, then why
can't it send the Request message directly? Why is it mentioned in the
draft that it should send the Request message to All DHCP Agents
Address? This situtation holds for renew and rebind message also.

Release Message
_______________

For sending DHCP Release message, does the client include addresses to
be released? (or) includes ONLY the address to be released?

Authentication Option
_____________________

Why authentication option is to be included as the last option?
If it is included as the first option, it will be easier to authenicate
first and in case, if authentication fails, it can directly reject the
packet without processing further.

Sending deprecated address
__________________________

Assume 
1. A network renumbering for a particular link has occured. The prefix
5ffe:: is changed to 3ffe::   
2. An IA for a node in this link has following addresses, 5ffe::20 and
5ffe::21
3. Now reconfiguration has been triggered and the server has sent the
Reconfigure-init message to the client.
4. Client has responded with DHCP Request. 

a) does the server has to delete the addresses 5ffe::20 and 5ffe::21
from the IA and include 3ffe::20 and 3ffe:21 in the IA?
(or)
b) for graceful renumbering, it can add new IP-address 3ffe::20 and
3ffe:21 to the IA along with the orginal 5ffe addresses? 
In this case, i feel that the old prefix addresses (5ffe) should be made
deprecated one with the prefered-lifetime = 0 and valid-lifetime = some
grace period. I think this is a MUST one for renumbering.

_______________________

* In the draft, in one section(12.3.2) , it is mentioned that, client
has to wait for ADV_MSG_TIMEOUT collecting the Advertise messages. In
another section( WAIT collecting Advertise message. Since both the
variable has different default values, which is to be used?

---

From: [email-masked]
Date: Mon, 12 Mar 2001 21:46:14 -0600

Vijay,

> "next fragment" for transmission of the fragemented packet?

IPv6 fragmentation is now end-to-end.  The DHCPv6 server is an IPv6 capable
node.  Hence, it MUST be able to reassemble IPv6 packets with Hdr Ext of
Fragment Header.  

> * How DUID is generated? what is its format?

Ted Mellon had an algorithm Ralph and I feel had "rough" consensus our hope
is Ted will write this up for us for last call.  But it is missing now yes.

> will unecessarily receive the Reconfigure-init  message.

If a server is multisited this will be useful.  So I think we need to keep
this multicast address.  Clearly we may need other ones and we should
document that.
 
> returning these generic error values. This option must be included in

Both of these came out of when we had DNS support in dhcpv6.  We should
review each error condition and if it is not referenced it should be
removed.  Also we should see if we are missing any.  Ralph and I found
several new ones we needed in draft 17 for those watching this.  We need to
get these right for last call.

If you have ideas of where we might use new ones or existing ones it would
be very cool if you tell us too.  Thanks.....

> send the DHCP Request message.

In draft 18 that is implied. In 12.3.1 

The client MUST include options for any IAs to which the client is
   expecting to have the server assign addresses.  Because the client
   does not have any IAs with addresses when sending a Solicit message,
   all of the IAs MUST be empty.  The client MAY include an Option
   Request Option in the Solicit message.  The client MUST NOT include
   any other options except those specifically allowed as defined by
   specific options.
> 
> >The server MUST include options to Advertise message 
> containing any address >that would be assigned to IAs 
> contained in the Solicit message format. 
> 

Yes.

> "n" address in the IA? (or) need to send the just the prefix?

No.  The server can respond with no options too.  Or just the addresses it
wants to give.  

> parameters, will it tollaly ignore the Solicit and don't send reply?

The server only sends an advertise to a solicit.  Not a reply.  Do you want
to reread the advertise server section again? But the server is free to send
something or nothing as options in advertise. 

> with the available number of IP-address (OR) doesn't send Advertise?

In advertise there is not mandate for response other than the header msg but
servers who do with equal preference level will most likely get used by the
client.  We did write this all down?

> to the other clients and is reserved for the client that has sent the

That is what a smart server should do.  A dumb one won't.  :-----) 
We can probably add a server should keep the addresses for x time.

> Request message

We should bring this up on the design conference call.  We don't say now.
We had long discussions on this mailing list about not permitting clients to
do this.  But we do permit clients to request a number of addresses in the
Request.  If we permit this I would suggest it can be done at Renew.  But
this needs to be discussed.

> treat these two as different or same IAs?

Good question.  The IA DUID identifies the address set for a client.  Right
now should there be any duplicates the prefix avoids that as the prefix in
IPv6 cannot be duplicated AS LONG AS ITS a GLOBAL PREFIX if the server is
multisited.  So there is a one-to-one relationship btw the clients addresses
and a DUID and prefix today. 

If the server gets another IA from the same client right now in the spec
there is no way to differentiate that they are connected to the same client
at all.
See my next mail to Bernie on his question.  Ralph and I caught this in the
spec and were going to bring it up under DUID and Prefix.  But see my next
mail to Bernie on him asking about client identification.

> b) why empty IA is to be sent for requesting IP address?

A Request message is for the first time the client requests addresses.  See
Confirm, Renew, and Rebind text.
> fields to be filled in IA options for sending the empty IA.

We force you right now to fill in num-addrs and zero filled address for each
one.  The reason is that working group consensus was that there is benefit
in constant IA set of fields.  We could discuss just sending upto prefix
length?

> I think these are fields which must be filled.

I agree but this means altering how much of the option we send.  We can
discuss I think lets bring it up.  You should send specific wording for
topics you want to discuss on the design con call is my suggestion.  That
way it is easier for Ralph to record in separate mail thread or send to
Ralph privately and cc me if you like.
 
> life time should be present or filled with zeros?

This is an omission.  Yes.  Unless we don't send them.

> Address? This situtation holds for renew and rebind message also.

Good catch.  That should only apply to the Request.  In fact by definition
only the server that provided the addresess can Confirm or Renew.  So those
should be sent directly to them.  On Rebind the client can remember other
servers and send to them directly or use Multicast.  

For Request the idea was to permit the client to avoid having to recall the
relays address if when it still does not have a routable ip address. 

We should clarify on design call.

> Release Message

The client must include ONLY the addresses to be released.

> Authentication Option

I will let Ralph answer this.  This is TBD we ran out of time for this
draft.

> Sending deprecated address

Not if the valid life time has not expired.

> grace period. I think this is a MUST one for renumbering.

I believe this is a good policy and a good idea.  But I do not think we can
mandate how that is done in the spec.  We could have an appendix like this
though?

Sounds like we have a typo problem but I could not find the other missing
WAIT?  Can you send to me privately.

thanks for the thorough review,
/jim