Subject: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-01.txt

From: [email-masked]
Date: Sat, 15 Sep 2012 11:05:03 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : Enterprise IPv6 Deployment Guidelines
	Author(s)       : Kiran K. Chittimaneni
                          Tim Chown
                          Lee Howard
                          Victor Kuarsingh
                          Yanick Pouffary
                          Eric Vyncke
	Filename        : draft-ietf-v6ops-enterprise-incremental-ipv6-01.txt
	Pages           : 28
	Date            : 2012-09-15

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 potentially 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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-ipv6

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-enterprise-incremental-ipv6-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Sep 2012 07:36:17 -0700

Here are my comments on this document:

Fred
[email-masked]

1) Section 1, s/will be perform better/may perform better

2) Section 1, "It is thus in the enterprise's interests to
deploy native IPv6 itself." - This statement is not necessarily
true for all enterprises, and the fact that the ISP may provide
native IPv6 services has no bearing on whether the enterprise
should also provide native IPv6 services. Suggest deleting this
sentence.

3)Section 1.3, "Reasons for a Phased Approach", in this
section there should be a statement to the effect that,
although some of the RFC1687 reasons for not deploying
IPv6 are still valid, many of the reasons given in this
section are new since the publication of RFC1687 and do
give good reasons for transition.

4) Section 1.3, the statement: "it can be expected that
new applications will only support IPv6." Please change
to: "it can be expected that some new applications will
only support IPv6."          ^^^^

5) Section 1.3, "which means that with IPv6 merging networks
(after two organizations merged) is much easier and faster."
This statement needs to be backed up with a citation - perhaps
something from the RENUM working group, or from "Renumbering
Without a Flag Day".

6) Section 3.1.2, "...communicates of the network" - should it
be: "...communicates on the network" ?

7) Section 3.1.2, second paragraph, somewhere this paragraph
should cite RFC6724 - "Default Address Selection for Internet
Protocol Version 6 (IPv6)".

8) Section 3.3, final sentence: "Either way IPv6 introduces
the opportunity to rationalize the environment and to architect
it for growth." - is not true, because IPv6 is an inanimate
object and cannot "introduce" anything. Maybe you are meaning
to say (sic) since the network administrators are considering
an introduction of IPv6 they might also be inclined to review
their existing architecture for its growth potential while they
are at it? Plus, this statement and the previous paragraph are
out of place in a section that is supposed to talk about routing.

9) Section 3.5, the sentence: "The enterprise administrator will
want to evaluate whether the enterprise will request address space
from its ISP (or Local Internet Registry (LIR)), or whether to
request address space from the local Internet Registry..." - the
term "local Internet registry" is being used redundantly here in
a way that may confuse the reader.

10) Section 3.5, "Each location, no matter how small, should get
at least a /48." - there has been quite a bit of discussion about
sites being able to request a smaller size such as /56. Also, the
size of the minimum site prefix is outside the scope of this
document. Perhaps change this to something like: "Each location,
no matter how small, should get the largest practical IPv6 prefix
delegation.".

11) Section 4.1, "may need to communist with the outside world",
"communist" is probably not the correct word here.

12) Section 4.1, "Add some comment about setting MTU to 1280 to
avoid tunnel pMTUd black holes?" - This is out of scope for this
document, and goes against recommendations in some of the tunneling
documents. Plus, 1280 may not be any safer than something larger
like 1480 in many cases.

13) Section 5, the phrase "Dual Stack when you can, tunnel when
you must" may be inappropriate for some or perhaps even many
enterprise network use cases. The subsequent sentence also
contains subjective advice. Suggest rewording the first two
sentences of this paragraph to something like: "An important
design paradigm to consider during this phase is to determine
where Dual Stack and/or tunnel should be used".  Dual stacking
when possible allows you to build a native IPv6 network
capability that should be preferred over tunnels."

14) Section 5.1, "An important design choice to be made is what
IGP to use inside the network." - Doesn't this text belong back
in Section 3.3 ("Routing")? Or if not, should Section 3.3 be
deleted and its text moved here?

15) Section 5.1, final sentence, "In the long term, DHCPv6 makes
most sense for use in a managed environment." would almost
certainly raise prolonged and undesirable debate. The previous
sentences articulated the SLAAC and DHCPv6 considerations very
well, so it would be better to just leave this sentence out.

16) Section 5.2, "It is important to note that most operating
systems will, by default, prefer to use native IPv6 over IPv4
when enabled." - this may not be true for OSes that implement
RFC6724 default address selections. In that case, IPv6 and/or
IPv4 would be preferred based on the address selection
algorithm instead of based on some static configuration.

17) Section 5.2, "Furthermore, some OSes may have tunneling
mechanisms turned on by default...". Change to: Furthermore,
some OSes may have unmanaged tunneling mechanisms turned on
by default..."     ^^^^^^^^^ 

18) Sections 6.2 and 7 seem to be preliminary in nature, and
seem to be in need of substantial editing and/or new text added.
It is too early to comment on these sections.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Saturday, September 15, 2012 11:05 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-
> 01.txt
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: KK <[email-masked]>
Date: Sun, 23 Sep 2012 18:18:10 -0700

Fred,

Thank you for your detailed comments and apologies for a delayed response.

This is very useful feedback! We will work on incorporating these changes
into the next revision.

Regards,
KK

On Thu, Sep 20, 2012 at 7:36 AM, Templin, Fred L
<[email-masked]>wrote:

> > Subject: [v6ops] I-D Action:
> draft-ietf-v6ops-enterprise-incremental-ipv6-
> > 01.txt
> >
> >