Skip to main content

Telechat Review of draft-ietf-6renum-enterprise-05

Request Review of draft-ietf-6renum-enterprise
Requested revision No specific revision (document currently at 06)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2013-01-08
Requested 2013-01-03
Authors Sheng Jiang , Brian E. Carpenter , Bing Liu
I-D last updated 2013-01-10
Completed reviews Genart Telechat review of -05 by Wassim Haddad (diff)
Secdir Last Call review of -04 by Yaron Sheffer (diff)
Secdir Telechat review of -05 by Yaron Sheffer (diff)
Assignment Reviewer Yaron Sheffer
State Completed
Request Telechat review on draft-ietf-6renum-enterprise by Security Area Directorate Assigned
Reviewed revision 05 (document currently at 06)
Result Ready
Completed 2013-01-10

version -05 of the draft responds to all the concerns I had with -04. I 

have no additional comments.


On 12/14/2012 12:34 PM, Yaron Sheffer wrote:

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.

This document reviews best practices in renumbering IPv6 enterprise

I apologize for my belated review, and hope it is still useful to the
authors and document reviewers.


The Security Considerations section appears appropriate for this type of
document. I do not see any issues that should block the document from


- Usage of FQDN: I don't understand why RFC 5996 (IKEv2) is cited, I
suspect this is a typo. Otherwise, please clarify.
- The "Security" subsection of 4.1 overlaps with the Security
Considerations section, and I would recommend to consolidate them.
- 4.1, "Miscellaneous": I accept the recommendation to use FQDNs instead
of IP addresses. But saying "connections can survive" implies to me that
live TCP connections will survive an IP renumbering event, which is not
the case. I would say "connectivity to the remote side can survive"
- 4.3: RFC 2230 is mentioned as a way to deal with naming of IPsec
endpoints. I am not aware of current implementations of this RFC (in
fact it is not even mentioned in the current IPsec Roadmap document, RFC
6071). Moreover, there is community consensus that IPsec should not be
used in the absence of a key management protocol. And IKE/IKEv2
certainly supports naming/identifying endpoints by FQDN.
- The Security Considerations are sufficient IMO. The first point (using
renumbering to escape blacklisting) is appropriate in the context, even
if per Martin Stiemerling's comment, this strategy may not be very
effective. This is not a recommendation on how to bypass blacklisting,
just a description of a potential vulnerability.