Document: draft-huston-6to4-reverse-dns-07.txt
Reviewer: David Black
Review Date: 17 July 2007
IESG Telechat date: 19 July 2007

Summary:
This draft is on the right track, but has open issues,
described in the review.

Comments:

The draft is in generally good shape, but I think the first
two potential issues noted in Section 4 Delegation Administration
need further attention:

   o  Clients inside a 6to4 site could alter the delegation details
      without the knowledge of the site administrator.  It is noted that
      this is intended for small-scale sites.  Where there are potential
      issues of unauthorized access to this delegation function the
      local site administrator could take appropriate access control
      measures.

Independent of intent, this will get used for larger scale sites.
Some form of prefix control exercisable by the site administrator
would be a good idea.  This may not be possible in all cases as
details of provider address allocation aren't always available
beyond the address block allocated by the registry, but the topic
needs some more thought.  Failing that, this is a v6 firewall
configuration issue, and the need for a firewall to support this
for administratively-controlled multi-address sites should be
called out in the Security Considerations section.

   o  IPv4 DHCP-based 6to4 sites, or any 6to4 site that uses
      dynamically-assigned external IPv4 interface addresses, could
      inherit nonsense reverse entries created by previous users of the
      dynamically assigned address.  In this case the client site could
      request delegation of the reverse zone as required.

This is an invitation to serious problems.  There ought to be a
way in the service to add a delegation expiration time when a
delegation is requested (e.g., a slightly smart piece of client
software could then put in the DHCP lease expiration time and
update the delegation when renewing the DHCP lease).  Inheriting
someone else's reverse DNS delegation because DHCP re-allocated
the IP address is not what I would consider expected behavior.

Nits:

idnits 2.04.12 didn't like some of the boilerplate

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC
4748:
 
------------------------------------------------------------------------
----

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** This document has an original RFC 3978 Section 5.5 Disclaimer,
instead
     of the newer disclaimer which includes the IETF Trust according to
RFC
     4748.

It also found a missing reference:

  Checking references for intended status: Informational
 
------------------------------------------------------------------------
----

  == Missing Reference: 'DNS' is mentioned on line 83, but not defined

Finally, idnits complained about IP addresses, but I think the address
usage in the draft is correct.