Subject: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt> (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

From: The IESG <[email-masked]>
Date: Fri, 29 Mar 2013 06:03:26 -0700

The IESG has received a request from the Operational Security
Capabilities for IP Network Infrastructure WG (opsec) to consider the
following document:
- 'Security Implications of IPv6 on IPv4 Networks'
  <draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt> as
Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2013-04-12. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document discusses the security implications of native IPv6
   support and IPv6 transition/co-existence technologies on "IPv4-only"
   networks, and describes possible mitigations for the aforementioned
   issues.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4-nets/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4-nets/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Mar 2013 13:38:11 +0000

Hi,

My minimal request for this draft is for my name to be removed from
the Acknowledgements, as I do not think that my comments have been
acted on.

In fact, I think that in its current state, this document is harmful
to IPv6 deployment. It in effect encourage sites to fence themselves
into an IPv4-only world. Particularly, it explicitly suggests a
default/deny approach to IPv6-in-IPv4 tunnels, which would prevent
the typical "baby steps" first approach to IPv6 deployment.

I would like to see the document convey a positive message, suggesting
that an IPv4 site first decides which IPv6 deployment mechanism it
will use, and then configures security appropriately (to allow that
mechanism and block all others). This wouldn't affect the technical
recommendations much if at all.

A specific aspect of this is that if a site provides one well-managed
6in4 tunnel mechanism, all tunneled IPv6 packets will pass through
well-defined points where security mechanisms may be applied.

We shouldn't imply that not having an IPv6 plan and blocking all IPv6
by default is a sound strategy.

Regards
   Brian