Re: New I-Ds on ftp.bucknell.edu

[Yakov Rekhter <[e-mail]>]

Jim,
  
> Regarding draft-ietf-dhc-dhcp-dns-00.txt
> 
> I have no real technical issue with the strategy but some comments on
> "use" and the effects to "policy".  Under the Applicability to IPv6 the 
> wording needs some work, as DHCPv6 and IPv6 bring new capabilities and
> technical assumptions to the issues.  I will propose the wording below.
> 
> Who updates what/when/which:
> 
> I believe if a client can update A records it will also be able to
> update PTR records.  

While in principle this could be added to the document, I don't 
understand why in practice you'll need this option.

> Under Discussion:
> 
> Discussion #1 Configure server to perform IP to FQDN mappings:
> 
> If the client owns the mapping the client does the update.

With DHCP the client *does not* own the IP address. So, the client
can't own the IP to FQDN mapping.
  
> Discussion #2 Duration of Lease reflected in DNS updates:
> 
> We cannot set the TTL in this manner.  The TTL reflects the caching for
> an address not a policy for time of use for an address.  In BIND the TTL
> is used to optimize the propogation of locating addresses quickly.  It is
> not mean't to be used for a "policy" for how long an address is used
> for by a "node".   Also if the lease is infinite we don't want infinite
> TTLs.  If we want lease times associated with DNS they need to be new
> DNS records.  But I don't see their use for control of address expiration
> and this should be left to the server or client.

There is a need to propagate the lease information to DNS. Use of
TTL is just one option. Can you suggest some other option(s) ?

> Discussion #3   Server deleting a PTR record:
> 
> Regarding the server deleting the PTR record.  This needs much WG
> discussion.  The issue is should a server delete anything but addresses for
> a client?  I think the client always must initiate the DNS update
> (meaning change too).  But I think implementations should be able to
> configure the policy needed if this is to be done by a server.  

Ok. Let's talk about this at the IETF.
  
> My input to the WG is as follows.  This gets into an issue of "policy".
> What we should do now is state the mechanisms that can be used to
> implement different policies for changes to the DNS per addresses
> expiring or being renewed.  Users will want this done in different
> manners depending on their particular philosophy for their distributed
> network environment.

Agreed.
  
> Also I think any deletions must occur after the address is invalid not
> during the deprecated state because if the address is renewed the DNS
> will not change, unless the client wants a new name.  This is more of an
> IPv6 issue but could be applied to the T1/T2 timer fields in DHCPv4.

Agreed.
  
> Here are the possibilities off the top of my head:
> 
>   1.  Client owns all updates.  Server not needed.  This is the easy
>       case for the server.

Let's talk more on this scenario at the WG meeting.

>   2.  Client owns update of A records but Server owns update of PTR records.
> 
>       A record expires:  
> 
>         CASE 1:
>         In this case the client owns the A record so if they delete
>         it they need to inform the server this has happened. The server
>         then deletes the PTR record.

Once the lease expires both the client (if the client is up) and the
server (if the server is up) would notice that. Why do we need the
client to inform the server that the lease expired, and the client
would update the A RR ?

>         CASE 2:
>         A policy exists that when an address expires the server is
>         to delete the PTR record.  This policy can be set when
>         DHCP is configured or in an option for each client.  
>         I personally believe it will be determined by users at 
>         each subnet.

I think that this shouldn't be an option. Once the lease expires, the
information carried in the PTR RR is incorrect. Why not invalidate it ?

>   3.   Server owns both updates of A and PTR.
> 
>        CASE 1:
>        Client controls server operation with msg types or options.
> 
>        CASE 2:
>        Server uses policy as in CASE 2 in #2 above.
> 
> 
> Discussion #4  Server terminates lease before lease expires:
> 
> This gets into the lack of robustness in DHCPv4 when a server wants to
> terminate a lease before its time expires.  There is no way to
> communicate to the client unless a transaction is in process initiated
> by the client, as DHCPv4 clients don't listen on a port for any server
> initated messages.  In DHCPv4 I don't think we should just delete A or
> PTR records in this case as its very rude and I don't think users will
> want such a policy.  For example I am running an application that
> verifies its address with DNS like rlogin and the connection breaks
> without any knowledge to the client.  We fix this in DHCPv6.

I don't think DHCPv4 server can terminate a lease before the lease
expires without getting a RELEASE message from the client.
  
> Applicability to IPv6:
> 
> FIRST: Do you need to send this to the DHCPv6 list its different than
> the DHCPv4 list?
> 
> I would state the following (if my co-author Charlie Perkins agrees):
> 
> ---------------------------------------
> The procedures described in this document are applicable to an IPv6
> client, but as the DHCPv6 protocol is different the exact mechanisms may
> be different, and new capabilities may exist in DHCPv6 that are outside the 
> scope of DHCPv4.  The procedures should be documented and inherent in the
> DHCPv6 specification as a new protocol.
> 
> Add a reference to Bound/Perkins DHCPv6 spec (which will be out soon but
> you can use the present ID for reference if you cannot wait)
> ---------------------------------
> 
> The DHCPv6 architecture is completely different and the scope and
> capability of that protocol also deals with addresses leases completely
> differently.  We have also added new capabilities directly because of
> the new features in IPv6.  I think the above wording covers the changes.
> The spirit of what your proposing is fine for DHCPv6 but it will be done
> differently as you will see in our next draft to be presented at the
> L.A. IETF meeting.

Fine by me. In fact, we could take the whole section on the
applicability to IPv6 out.
  
Yakov.