Fernando, Rather than repeating myself, I'll suggest a change to the Introduction that would (IMHO) improve the message: OLD: 1. Introduction Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/co-existence technologies by default. For cases in which the corresponding devices are deployed on networks that are assumed to be IPv4-only, NEW: 1. Introduction Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/co-existence technologies by default [RFC6434]. Support of IPv6 by all nodes is intended to become best current practice [RFC6540]. As a result, networks will need to plan for and deploy IPv6 and its security mechanisms. Some enterprise networks might, however, choose to delay active use of IPv6. For networks that are assumed to be IPv4-only, It would be nice to refer to draft-ietf-v6ops-enterprise-incremental-ipv6 but I think that is too far from RFC publication to be very useful. Regards Brian On 01/04/2013 14:04, Fernando Gont wrote: > Brian, > > On 03/29/2013 10:38 AM, Brian E Carpenter wrote: >> 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. > > That has been my intent, and I sent a note before publishing one of the > latest revs to double-check that (not sure if I missed your respond, or > you didn't respond). > > >> 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. > > Sites that implement any kind of security policy employ a "default deny > policy" (for the simple reason that it's safer to open holes than > explicitly close them). The bottom-line is that if your site enforces > any kind of security policy, you should make an explicit decision > regarding what you do with v6, rather than being unaware that it's there > in your network. > > > >> 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). > > There's an operational gap here: in many cases, operators have no tools > to enforce security policies on such tunneled traffic. > > Besides, when thinking about v6, enterprise networks and the like should > be doing native IPv6 (in which case v6 security controls would be > enforced throughout the network), rather than having each node go their > own way. > > >> 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. > > In which case you'd be "enforcing IPv6 security controls", which is > entirely in-line ith what this document is saying. > > >> We shouldn't imply that not having an IPv6 plan and blocking all IPv6 >> by default is a sound strategy. > > It's not, and I don't think we're implying that. However, I'd note that > some people are in the position of blocking traffic, or not doing > anything about it. Check for IPv6 support in different security > products, and you might get depressed. > > Cheers,