RE: [dhcwg] additional option for dhcpv6

["Bernie Volz (EUD)" <[e-mail]>]

My feeling is that we should follow the work being done in DHCPv4 in this area (FQDN) as defined by draft-ietf-dhc-fqdn-option-03.txt. Whether we also have a host name option is still TBD - I believe Carl Smith and Ted Lemon will be working up some text for DHCPv4 and it would be good to wait until we have some clear definitions around proper behavior and interactions between the host name, domain name, and FQDN options. Unless there are some significant reasons to defer from DHCPv4 options, I would recommend using the DHCPv4 options as closely as possible. We have a lot of experience with those options already!
 
- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:[e-mail]]
Sent: Sunday, January 20, 2002 1:56 PM
To: 'Bernie Volz (EUD)'; [e-mail]
Cc: [e-mail]; Vijayabhaskar A K (E-mail)
Subject: RE: [dhcwg] additional option for dhcpv6


Bernie,
I didn't talked anything about DDNS updates for temporary addresses. What i have defined is similar one like "hostname" option (option 12) in  DHCPv4. It has the same functionality as option 12 in DHCPv4. If there is any FQDN related to address assigned, i wanted an option that informs the FQDN to client. This can be used for transfering hostnames/FQDN from client to server and vise versa. This holds for both normal addresses and temp addresses also. It is just a "hostname" option not an FQDN option.
 
Since, DDNS updates is still TBD, i don't know, what are the fields needed for FQDN option. Let us decide whether the client or server is doing dns updates. Then based on that,we can decide the fields on FQDN option. I feel that if we are strictly moving some part or complete dns updates to client, we don't need one or both of the RCODE*.  Do correct me, if i am wrong. 
 
Vijay: 

I don't understand your desire to do DDNS updates for temporary addresses. We specifically do NOT want to do them. The -22 draft just says that if a server does DDNS updates, it must follow the rules of RFC 3041.

I think you have things backwards a bit. Non-temporary addresses are the addresses that need domain names (FQDNs) assoicated with them. Temporary addresses really shouldn't since that defeats the purpose of temporary addresses. However, what RFC 3041 says, is that if DDNS updates are done, the name should be something that doesn't identify the client. It gives one reason for doing this and that is to keep applications happy that "authenticate" clients by doing a reverse and then forward lookup to assure the client is in DNS. 


 We need a general FQDN option. Where it is placed (encapulated within the option area of an IA Address option, inside the option area of an IA option, or outside IA options) determines its scope (to one address, several addresses, or all addresses). For temporary addresses, the scope should be to that one address (since even using the same name with two temporary addresses could leak information about the client).

So, I see no value in an option that is just for temporary addresses. We should define a FQDN option and use it whenever DDNS updates are done. The format should be defined as in draft-ietf-dhc-fqdn-option-03.txt with the following differences:

- a 16-bit option number/option length 
- "A" RRs replaced by "AAAA" RRs. 
- Name encoding should be as per section 10 of the -22 draft on DNS encodings (hence we technically don't need the "E" bit in the flag field but I would recommend we simply specify it MUST always be set to allow common code to be used on the client and/or server).