[DNSOP] FWD: Document Action: '6to4 Reverse DNS Delegation Specification' to Informational RFC

[Peter Koch <[e-mail]>]

Dear WG,

FYI, draft-huston-6to4-reverse-dns-07.txt, reviewed here upon request of the
IAB, was approved by the IESG.  Thanks a lot to all involved!

-Peter

----- Forwarded message from The IESG <[e-mail]> -----

From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>,
        RFC Editor <[e-mail]>
Subject: Document Action: '6to4 Reverse DNS Delegation 
 Specification' to Informational RFC 
Date: Tue, 22 Jan 2008 17:35:54 -0500

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.
_______________________________________________
DNSOP mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/dnsop