Enterprise IPv6 Deployment Guidelines
draft-ietf-v6ops-enterprise-incremental-ipv6-06

[Ballot comment]
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!

[Ballot comment]



- 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.

[Ballot discuss]
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!

[Ballot comment]
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.

[Ballot comment]
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

[Ballot comment]


- 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

[Ballot comment]
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.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-v6ops-enterprise-incremental-ipv6-05, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Enterprise IPv6 Deployment Guidelines) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Enterprise IPv6 Deployment Guidelines'
  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
ietf@ietf.org mailing lists by 2014-06-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Enterprise network administrators worldwide are in various stages of
  preparing for or deploying IPv6 into their networks.  The
  administrators face different challenges than operators of Internet
  access providers, and have reasons for different priorities.  The
  overall problem for many administrators will be to offer Internet-
  facing services over IPv6, while continuing to support IPv4, and
  while introducing IPv6 access within the enterprise IT network.  The
  overall transition will take most networks from an IPv4-only
  environment to a dual stack network environment and eventually an
  IPv6-only operating mode.  This document helps provide a framework
  for enterprise network architects or administrators who may be faced
  with many of these challenges as they consider their IPv6 support
  strategies.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-ipv6/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-ipv6/ballot/


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

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page header?

The draft is intended to be at, and requests, Informational status.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

This document summarizes a proposed framework for enterprise network
architects and administrators as they plan the introduction of IPv6
support in their environments, specifically dual stack and eventually IPv6
only.

Working Group Summary:

This draft was first submitted as
draft-ietf-v6ops-enterprise-incremental-ipv6-00.txt in August 2012. The
document has been revised several times since introduced. The document
outlines considerations, both technical and logistical, that enterprise
adopters of IPv6 should consider as they advance or even begin introducing
support for IPv6 across their respective enterprises.

The draft has been discussed at length and in detail.

Document Quality:

As specified in the abstract, the document is not a protocol or procedure;
the document outlines topics that enterprise adopters should consider when
planning for the adoption of IPv6. The document touches on areas that
would be typically be present when planning an IPv6 adoption project so
several are the items focus on non-technical aspects of an enterprise IPv6
deployment.

Personnel:

The document shepherd is John Jason Brzozowski. The responsible AD is Joel
Jaegli.

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

In the view of the chairs, this document is ready for publication, having
been reviewed and commented on by the working group. The shepherd tracked
working group commentary. The shepherd also read the document and ran it
through idnits.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

I have no issues with the document as it stands.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79
have already been filed. If not, explain why?

The authors tell me that they know of no outstanding IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

Per
http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-iet
f-v6ops-enterprise-incremental-ipv6, there are no relevant IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

WG consensus is solid for this document. Since it is largely focused
planning and logistics for enterprise IPv6 deployments there seemed to be
little contention around the document. Various comments and edits from
adopters have been factored into the document to help with completeness.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

idnits was run on draft-ietf-v6ops-enterprise-incremental-ipv6-05, no
issues were reported.

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

Irrelevant.

(13) Have all references within this document been identified as either
normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

Not applicable.

(15) Are there downward normative references references (see RFC 3967)? If
so, list these downward references to support the Area Director in the
Last Call procedure.

The normative references are all to informational, BCP, or standards track
documents. As an informational document, these are not downward references.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the
document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

The document doesn't change the status of any RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that newly created IANA registries include a detailed specification of the
initial contents for the registry, that allocations procedures for future
registrations are defined, and a reasonable name for the new registry has
been suggested (see RFC 5226).

This memo includes no request to IANA, and says as much.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

There are none.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None. There is no formal language in the document.