Skip to main content

Last Call Review of draft-ietf-v6ops-464xlat-08
review-ietf-v6ops-464xlat-08-secdir-lc-hanna-2013-01-03-00

Request Review of draft-ietf-v6ops-464xlat
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-12-21
Requested 2012-12-13
Authors Masataka Mawatari , Masanobu Kawashima , Cameron Byrne
I-D last updated 2013-01-03
Completed reviews Genart Last Call review of -08 by Miguel Angel García (diff)
Secdir Last Call review of -08 by Steve Hanna (diff)
Assignment Reviewer Steve Hanna
State Completed
Request Last Call review on draft-ietf-v6ops-464xlat by Security Area Directorate Assigned
Reviewed revision 08 (document currently at 10)
Result Ready
Completed 2013-01-03
review-ietf-v6ops-464xlat-08-secdir-lc-hanna-2013-01-03-00
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 describes an architecture for providing IPv4 connectivity
across an IPv6-only network. I'm not a fan of documents where the
Security Considerations section just says "See these other two specs
for the Security Considerations" but in this case it seems that this
is adequate. This document is effectively recommends a concatenation
stateless v4/v6 translation on the customer side and stateful v6/v4
translation in the provider so it does make sense that the combination
of the RFC 6145 and RFC 6146 Security Considerations would do it. And
a review of those documents shows that their Security Considerations
are thoughtful and well-considered.

I did find a few minor typos in section 8.2. In the first paragraph:

"a explanation" should be "an explanation"
"using combination" should be "using a combination"
"is delegated IPv6 prefix" should be "is delegated an IPv6 prefix"

Those were the only typos or errors that I found.

Note that I am not an expert in address translation or IPv6 operations
so there could be hidden security issues here that I didn't find.