6to4 Reverse DNS Delegation Specification
RFC 5158

[Ballot discuss]
Agree with Dave that it should at least be discussed within Softwires. We have blocked other informational documents based on this in the past, so I would hate to show preferential treatment.

[Ballot discuss]
This idea moderately violates the agreement w/ the softwires working group that V4-V6 transition tunneling technology would not be brought forward until softwires work was completed. Since it is is mostly similar technology similar to softwires should it fall under that agreement? SHould it be discussed w/in the softwires WG?

[Ballot comment]
Great document. Thanks for writing this. One
question or a comment, however:

> o The 6to4 site must have configured a minimum of one primary and
>  one secondary server for the 6to4 IPv6 reverse address zone.

Why do you require a secondary server as well? Sites
such as someone's home network would probably not have
multiple servers, and the configuration of a secondary
server would be a burden. (Unless, of course, both
servers point to the same node which would defeat
the purpose of having a secondary server.)

[Ballot discuss]
Based on the Gen-ART Review by David Black.

  There are two potential issues noted in Section 4 Delegation
  Administration need further attention.
 
  First:
  >
  > 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.

  Second:
  >
  > 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.

[Ballot discuss]
This document should reference RFC 3964, "Security Considerations for 6to4".  Specifically, does
the mechanism described in this document positively or negatively impact the four classes of
problems identifed in Section 7 of 3964?  Are new security problems created by this mechanism?

IANA Evaluation Comments:

We understand that this Internet-Draft documents
the delegation of 2.0.0.2.ip6.arpa.
However the delegation has already been made.

Please let the IANA know if our understanding is
incorrect.

a) Who is the Document Shepherd for this document?  Has the
  Document Shepherd personally reviewed this version of the
  document and, in particular, does he or she believe this
  version is ready for forwarding to the IESG for publication?

  $me (Peter Koch) will act as the proto shepherd, have reviewed this
  and previous versions and believe it is ready for publication.

b) Has the document had adequate review both from key WG members
  and from key non-WG members?  Does the Document Shepherd have
  any concerns about the depth or breadth of the reviews that
  have been performed?

  The draft has passed a dnsop WGLC that led to some changes. In addition,
  the chairs requested review by the security area directorate that was
  provided by Catherine Meadows.

c) Does the Document Shepherd have concerns that the document
  needs more review from a particular or broader perspective,
  e.g., security, operational complexity, someone familiar with
  AAA, internationalization or XML?

  There are no such concerns. The draft was reviewed for the
  security area directorate (see above) and the last call was
  brought to the attention of the v6ops WG.

d) Does the Document Shepherd have any specific concerns or
  issues with this document that the Responsible Area Director
  and/or the IESG should be aware of?

  This document still is an individual submission that was reviewed by
  the dnsop WG at the special request of the IAB v6 ad hoc group.
  It has been treated like a WG document except that it was never
  formally adopted.

e) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with
  others being silent, or does the WG as a whole understand and
  agree with it?

  The document describes a service aimed at a specific community (those
  using the 6to4 mechanism). Experience with and demand for this service
  might be limited within the WG, but the WG understands and supports the
  DNS related parts.

f) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?

  No.

g) Has the Document Shepherd verified that the document satisfies
  all ID nits?

  Yes.

h) Has the document split its references into normative and
  informative?  Are there normative references to documents that
  are not ready for advancement or are otherwise in an unclear
  state?

  The references are properly split. All normative references are to
  RFCs. One expired and supposedly dead I-D appears as an Informative
  Reference (mainly to give credit), a relevant excerpt is provided as
  a quote.

-----------------------------------------------------------------------------

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.