Last Call Review of draft-jiang-a6-to-historic-

Request Review of draft-jiang-a6-to-historic
Requested rev. no specific revision (document currently at 00)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-01-17
Requested 2011-12-21
Authors Sheng Jiang, David Conrad, Brian Carpenter
Draft last updated 2012-01-12
Completed reviews Genart Last Call review of -?? by Miguel García
Genart Last Call review of -?? by Miguel García
Secdir Last Call review of -?? by Phillip Hallam-Baker
Assignment Reviewer Phillip Hallam-Baker
State Completed
Review review-jiang-a6-to-historic-secdir-lc-hallam-baker-2012-01-12
Review completed: 2012-01-12


I have reviewed this document as part of the security directorate's

ongoing effort to review all IETF documents being processed by the IESG.

These comments were written primarily for the benefit of the security area

directors.  Document editors and WG chairs should treat these comments

just like any other last call comments.


A6 was a proposed replacement for AAAA records. A6 has not achieved the anticipated level of support or provided the anticipated benefits in practice. This draft moves A6 to historic, deprecating use of A6 records.


Removing A6 removes a potential source of inconsistency and thus improves consistency. 

One possible consequence of this particular change is that information that was previously expressible via the A6 mechanism will no longer be visible. While this is not necessarily good or bad from a security standpoint it is an issue that should be mentioned in the Security Considerations.

Another possible security impact is that it will not be possible to divide up administrative duties in the manner originally envisaged in the A6 proposal. While it is far from clear that this division is useful (or achievable) it should probably be noted. In particular it will not be possible to achieve renumbering of whole domains by changing one record.

It is quite possible that some domains will continue to employ A6 domains as an administrative convenience, generating the corresponding AAAA records as required. This case needs more consideration from a security point of view. It would be useful to require that such records be ignored by applications and preferably be blocked from external view.