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.