Enterprise IPv6 Deployment Guidelines
RFC 7381

Note: This ballot was opened for revision 05 and is now closed.

(Jari Arkko) (was Discuss) Yes

Comment (2014-06-26 for -05)
No email
send info
I just wanted to check that the authors and seen the in-depth review form Robert Sparks. I can not find a response, but it could be my e-mail system. Thanks!

(Joel Jaeggli) Yes

Comment (2014-06-25 for -05)
No email
send info
tom taylors review for the record.

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the
operational area directors.   Document editors and WG chairs should
treat these comments just like any other last call comments.


Revision reviewed: draft-ietf-v6ops-enterprise-incremental-ipv6-05

Summary:  The Gen-Art review by Robert Sparks was noted. In the light of that review it did not seem worthwhile to make further editorial comments (but I'm sure the RFC Editor will propose changes in a number of places). Some minor substantive comments are given below.

ID Nits: complains about use of RFC 2119 capitalization without a corresponding incorporation of the RFC 2119 boilerplate. A number of the references need updating.

Comments:

1. In Section 2.2.1, the implicit assumption is that IPv6 readiness is a binary condition, rather than an accumulation of features that the IETF is still trying to adjust. The authors may wish to warn administrators that they cannot necessarily take vendors' assessment of IPv6-readiness at face value, because definitions of that state may vary. Instead, the administrator needs to develop a checklist of elements of IPv6 implementation, and eventually will need to verify that these elements are functioning correctly, beginning in the vendor's lab if the IPv6 capability is not already present in the field.

2. While smartphones and tablets are addressed explicitly in Section 4.3, they are not mentioned in the lists of equipment given in the introductory sections 1 and 4. Just a suggestion that they be mentioned, perhaps as "mobile devices", so the reader doesn't get the impression that the advice in the document is dated.

3. Meta-comment: The hidden issue in Section 4.1 is the desire of enterprise administrators to control host configuration using DHCPv6 for security reasons, vs. the determination of a blocking plurality of IETF participants to reserve some configuration (e.g., default route) to basic IPv6 mechanisms only. IESG members who have not followed discussions of this topic should be aware that they were extensive, did not end in consensus, but did provoke expressions of frustration from enterprise-oriented operators, of the nature of: "Why should we bother to be here if you won't listen to us?".

Tom Taylor

(Benoît Claise) No Objection

Comment (2014-06-26 for -05)
No email
send info


- Section 1.3

Each administrator must decide whether
   to begin with the External Phase (as recommended in [RFC5211]) or the
   Internal Phase. 

A quick search in [RFC5211] doesn't help with the External Phase definition.
You should refer to section 3, and 4 respectively. 
Or ideally provide a quick definition here, because without definition I can't understand the bullet points (well, to be candid, I can guess, but you get my point)

- 
      It is worth noting that a number of emerging
      VPN solutions provide dual-stack connectivity; thus a VPN service
      may be useful for employees in IPv4-only access networks to access
      IPv6 resources in the enterprise network (much like many public
      tunnel broker services, but specifically for the enterprise).

You might want to point to http://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/

- OLD:
   It is generally recommend that the application
   developer use industry IPv6-porting tools to locate the code that
   needs to be updated.

NEW:
   It is generally recommended that the application
   developer use industry IPv6-porting tools to locate the code that
   needs to be updated.

- Might want to get a reference to RFC 7011 and 7012 in
   Moreover, if all the intra-enterprise traffic is
   encrypted, then this renders a lot of the network security tools
   (IPS, firewall, ACL, IPFIX, etc) blind and pretty much useless.

Same remark here
   Monitoring the use of the Internet connectivity should be done for
   IPv6 as it is done for IPv4.  This includes the use of IP Flow
   Information eXport (IPFIX) [RFC7012] to report abnormal traffic
   patterns (such as port scanning, SYN-flooding, related IP source
   addresses) from monitoring tools and evaluating data read from SNMP
   MIBs [RFC4293] (some of which also enable the detection of abnormal
   bandwidth utilization).  Where Netflow is used, version 9 is required
   for IPv6 support.
NEW:
Monitoring the use of the Internet connectivity should be done for
   IPv6 as it is done for IPv4.  This includes the use of IP Flow
   Information eXport (IPFIX) [RFC7011][RFC7012] to report abnormal traffic
   patterns (such as port scanning, SYN-flooding, related IP source
   addresses) from monitoring tools and evaluating data read from SNMP
   MIBs [RFC4293] (some of which also enable the detection of abnormal
   bandwidth utilization).  Where NetFlow is used, version 9 (RFC 3954] is required
   for IPv6 support.

- Section 3.3
I guess the title should be "Traffic Monitoring".
If it's not, you should speaking about syslog (over IPv6) as well.

Alissa Cooper No Objection

Comment (2014-06-25 for -05)
No email
send info
I was thinking some of the same things as Stephen regarding logging and IPSec.

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2014-06-25 for -05)
No email
send info

- 1.2: saying one should log stuff is probably right here.
However, it'd also be good to say something about protecting
those logs, (access to which could expose various things) 
and about periodically flushing them for privacy reasons if
that's not elsewhere. Just a sentence or two would probably
be fine.

- 2.4.1: I think the "pretty much useless" statement about
IPsec reads as if biased, which doesn't seem right. One
could argue that malware can benefit just as much as an IDS
from snooping on packets for example, even if that is
nowhere near as common today. Fixing the language in that
paragraph would be good so that it doesn't have to be
changed if malware migrates over time from end hosts to
e.g. the routers and switches within an enterprise network. 

- 4.3: is the text about smartphone support for IPv6 still
accurate? I don't know that its not, but it does read as
if written some time ago.

- 4.3: I wondered why there are no recommendations about
printers specifically when those only support IPv4. Is
there nothing to say about discovery there? I don't know
that there is but would have thought it possible.

- 4.4: would have thought that specific mention of web
proxies would be useful here - locally, we've had issues
with those even after mail all works fine.

- The secdir review spotted a few nits. [1]

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04843.html

(Brian Haberman) No Objection

Comment (2014-06-25 for -05)
No email
send info
Just a few non-blocking comments...

1. Section 2.1 takes a little too much time describing how the champion and project manager should run an IPv6 project.  I think this takes away from the key message of "plan ahead of time".

2. In Section 2.3, it is unclear if the training is meant for everyone in the organization or just those staff members responsible for managing/maintaining the network and the connected equipment.

3. Section 2.6 contradicts some entities approach of shrinking subnets to the smallest possible size in order to preclude rogue devices from attaching and obtaining an address.

Barry Leiba No Objection

(Kathleen Moriarty) No Objection

Comment (2014-06-26 for -05)
No email
send info
Overall, this is a very helpful draft, thanks for taking the time to do it.

I spotted similar things to Stephen and agree on the point of adding some mention of logging as well as log protecting.  I think there should also be mention in section 3.3, monitoring for external networks in addition to the earlier section Stephen referenced.  In case it is helpful for section 3.3 & 3.4, this would apply to the network (filters) as well as to servers and applications, not just firewalls.

Nit: first use of CDN in section 6.1 isn't spelled out.