The IESG has approved the following document: - '6to4 Reverse DNS Delegation Specification ' <draft-huston-6to4-reverse-dns-07.txt> as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-huston-6to4-reverse-dns-07.txt Technical Summary This document describes the service mechanism for requesting and maintaining a delegation for the DNS reverse mapping of 6to4 IPv6 address space within the 2.0.0.2.ip6.arpa domain via an automated interface. Publication Requested was in Oct 24. However, it fell through the cracks as it was not added to the tracker when the publication request was sent to the secretariat. ---- Working Group Summary The dnsop WG reviewed this document on request of the IAB. Document Quality The service is operational as described and is provided by the NRO. The 2.0.0.2.ip6.arpa zone contains several hundred delegations. --------- RFC Editor Note: Please add the following text to the Security Considerations section: For a general threat analysis of 6to4, especially the additional risk of address spoofing in 2002::/16, see [RFC3964]. Section 4 notes that the local site administrator could take appropriate access control measures to prevent clients inside a 6to4 site performing unauthorized changes to the delegation details. This may be in the form of a firewall configuration regarding control of access to the service from the interior of 6to4 site, or a similar mechanism that enforces local access policies. ----------------- Another RFC Editor Note: Current text The potential issues with this structure include: ... 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. Proposed text The potential issues with this structure include: ... 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. More generally, given the potential for inheritance of 'stale' reverse DNS information in this context, in those cases where the issues of potential inheritance of 'stale' reverse DNS information is a concern, it is recommended that a 6to4 site either use a static IPv4 address in preference to a dynamically-assigned address, or ensure that the reverse delegation information is updated using the service mechanism described here upon each dyanamic address assignment event. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
