Subject: [dhcwg] FQDN Option for DHCPv6

From: Maverick <[email-masked]>
Date: Tue, 26 Feb 2008 17:41:31 +0530

Hi All,

What is the rational behind not allowing FQDN option in Information-request?
I understand that there is no possible action that the server can take at
time when Information-request is received, but why is it made a must clause
in RFC?

*   A client MUST only include the Client FQDN option in SOLICIT,
   REQUEST, RENEW, or REBIND messages.*
-Thanks.
_______________________________________________
dhcwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 27 Feb 2008 08:41:40 -0500

Because what address(es) would you want the server to associate with the
FQDN?
 
There could be cases where a client has done a S/A/R/R and is now doing
an Information-Request to update or obtain some option, but in that
case:
1) Why didn't the client do the FQDN in the original S/A/R/R sequence?
2) Why can't the client do a S/A/R/R (or Request/Reply or Renew/Reply)
sequence if it now wants an FQDN.
 
There are also other issues with allowing the FQDN in an
Information-Request - such as the client-identifer is optional!
 
Can you give us an example of why you *WOULD* need to do this?
 
- Bernie
 
________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maverick
Sent: Tuesday, February 26, 2008 7:12 AM
To: DHC WG
Subject: [dhcwg] FQDN Option for DHCPv6

Hi All,
 
What is the rational behind not allowing FQDN option in
Information-request? I understand that there is no possible action that
the server can take at time when Information-request is received, but
why is it made a must clause in RFC?
 
   A client MUST only include the Client FQDN option in SOLICIT,
   REQUEST, RENEW, or REBIND messages.

-Thanks.
 
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg