Subject: [dhcwg] dhc WG last call on DHCP FQDN option draft

From: Ralph Droms <[email-masked]>
Date: Fri, 18 Feb 2005 16:02:45 -0500

This message announces a WG last call on "The DHCP Client FQDN Option"
<draft-ietf-dhc-fqdn-option-10.txt> and "The DHCPv6 Client FQDN
Option" <draft-ietf-dhc-dhcpv6-fqdn-02.txt>.  The last call on these
drafts will conclude at 1700EST, 2005-03-04.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Silence does not represent
positive support.  If there is no discussion, the document will not be
advanced to the IESG.

"The DHCP Client FQDN Option" specifies a DHCP for IPv4, DHCPv4,
option which can be used to exchange information about a DHCPv4
client's fully-qualified domain name and about responsibility for
updating the DNS RR related to the client's address assignment.  This
draft is available as
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-10.txt

"The DHCPv6 Client FQDN Option" specifies a new Dynamic Host
Configuration Protocol for IPv6, DHCPv6, option which can be used to
exchange information about a DHCPv6 client's fully-qualified domain
name and about responsibility for updating DNS RRs related to the
client's address assignments.  This draft is available as
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-02.txt

- Ralph Droms 

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

---

From: Stig Venaas <[email-masked]>
Date: Mon, 21 Feb 2005 22:13:13 +0100

I've been thinking of a possible issue regarding the fqdn option. You
have probably thought if it though, so I'm mainly wondering what your
thoughts are.

A client is supposed to use the S-bit to tell the server whether it
should update the A RR (or AAAA). I suppose this is based on whether
the client is able to perform the update itself, but that depends on
the value of the fqdn (or at least which zone it belongs to).

What I'm saying is, that for the client to tell the server what to do,
it may need to know what fqdn value the server will return.

One way of achieving that would be to do a DHCPDISCOVER first and
check what fqdn value the server will send perhaps.

In one way it might make sense for server to go ahead and update the
A record despite the S-bit being 0 if client sends one fqdn value in
the fqdn and server respons with a different fqdn. This might not be
the best way if client is able to do updates in multiple zones though.

I think this might be an issue, or is there something I haven't
thought of?

Stig

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Feb 2005 20:03:11 -0700

> the value of the fqdn (or at least which zone it belongs to).

The only time the client can do the update is if it knows its FQDN and 
knows how to do the update; otherwise, it needs to ask the server to do 
it.   We do not need to add any complexity here.   We just need this 
draft to be finished.

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 23 Feb 2005 08:33:19 -0500

Stig:

I think your issue is essentially the one Ted raised and that is why he
wanted text to say that the client doesn't have to honor the S-bit from the
server.

The S-bit sent to the server is expressing the client's desire FOR THE FQDN
it is sending (which may be none if it doesn't know it).

The S-bit received from the server is expressing what the server DID (or
will do) regarding the FQDN that the server RESPONDED with.

There are essentially two important cases:
1. The client is in a "home" network where it has a FQDN and security
information to do the DDNS update.
2. The client is in a "visited" network where the client's FQDN is
meaningless.

In case 1, it may make little difference who does the update (client or
server).

In case 2, there are actually two completely different DDNS updates that
COULD happen:

- One, by the DHCP server, in the visited network. Now, the server can't
update the client's home DNS since the server has no authority to. But, it
may still add a DNS name to its domain name (such as based on the IP address
or mac address). 

- Two, but the client, in the home network. If the client has the security
information to do this update, there is no reason not to allow it to do so.
That is why Ted didn't want the language to explicitly state that the
"Client MUST NOT do DNS updates".

So, it all depends on the FQDN that is returned by the server (and also that
the server returns the correct FQDN -- Ted was also concerned that some
servers in case 2 would return the client's original FQDN, not the local
FQDN).

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Stig Venaas
> Sent: Monday, February 21, 2005 4:13 PM
> To: [email-masked]
> Subject: [dhcwg] Question/possible issue regarding the fqdn option
> 
> 
> I've been thinking of a possible issue regarding the fqdn 
> option. You have probably thought if it though, so I'm mainly 
> wondering what your thoughts are.
> 
> A client is supposed to use the S-bit to tell the server 
> whether it should update the A RR (or AAAA). I suppose this 
> is based on whether the client is able to perform the update 
> itself, but that depends on the value of the fqdn (or at 
> least which zone it belongs to).
> 
> What I'm saying is, that for the client to tell the server 
> what to do, it may need to know what fqdn value the server 
> will return.
> 
> One way of achieving that would be to do a DHCPDISCOVER first 
> and check what fqdn value the server will send perhaps.
> 
> In one way it might make sense for server to go ahead and 
> update the A record despite the S-bit being 0 if client sends 
> one fqdn value in the fqdn and server respons with a 
> different fqdn. This might not be the best way if client is 
> able to do updates in multiple zones though.
> 
> I think this might be an issue, or is there something I 
> haven't thought of?
> 
> Stig
>

---

From: Stig Venaas <[email-masked]>
Date: Thu, 24 Feb 2005 09:43:20 +0100

> it.   We do not need to add any complexity here.   We just need this 

The client may know one FQDN and know how to update it, my concern was
when server returns another FQDN back which the client may not know how
to update. But in the last revision there is at least some wording
saying that the S-bit the client sets is regarding the actual FQDN value
it sends, and doesn't tell the server what to do if it returns a different
FQDN.

Bernie wrote:

This answers my question. I went back and checked that now the discussion
you and Bernie had a couple of weeks ago, and I see now that this was
actually one of the things you discussed. I should have read that again
before I posted.

Stig

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Feb 2005 08:44:58 -0700

On Feb 24, 2005, at 1:43 AM, Stig Venaas wrote:
> I should have read that again
> before I posted.

Nobody can blame you for not wading through our verbosity.   :')