Geoff and Peter,
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
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.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
