Document Action: '6to4 Reverse DNS Delegation Specification' to Informational RFC
The IESG <iesg-secretary@ietf.org> Tue, 22 January 2008 22:36 UTC
Return-path: <ietf-announce-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHRjI-0003vQ-1c; Tue, 22 Jan 2008 17:36:28 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHRjF-0003ug-KR for ietf-announce@ietf.org; Tue, 22 Jan 2008 17:36:25 -0500
Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHRjF-0005cM-77 for ietf-announce@ietf.org; Tue, 22 Jan 2008 17:36:25 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id D8A03175AA; Tue, 22 Jan 2008 22:35:54 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JHRik-0001bR-Do; Tue, 22 Jan 2008 17:35:54 -0500
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1JHRik-0001bR-Do@stiedprstage1.ietf.org>
Date: Tue, 22 Jan 2008 17:35:54 -0500
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: '6to4 Reverse DNS Delegation Specification' to Informational RFC
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Errors-To: ietf-announce-bounces@ietf.org
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 mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce