IPv6 Enterprise Network Analysis - IP Layer 3 Focus
draft-ietf-v6ops-ent-analysis-07

[Ballot comment]
The response to my DISCUSS position was much lighter than I had
  hoped.  I do not think the point is worth further delay.  I have
  changed my position to ABSTAIN.

State Change Notice email list have been change to v6ops-chairs@tools.ietf.org, fred@cisco.com, sklynsma@mitre.org, green@commandinformation.com, tjc@ecs.soton.ac.uk, jim.bound@hp.com, Yanick.pouffary@hp.com, townsley@cisco.com from v6ops-chairs@tools.ietf.org, fred@cisco.com, sklynsma@mitre.org, green@commandinformation.com, tjc@ecs.soton.ac.uk, jim.bound@hp.com, Yanick.pouffary@hp.com

[Ballot discuss]
> For secure autoconfiguration, the IPsec [IPSEC] or SEND method
> [SEND] can be used.

I would not like to recommend the use IPsec for securing
autoconfiguration. Most of the time autoconfiguration is not secured
beyond possible link layer protection. But when you need to secure it,
the use of IPsec is not really a viable option. People that tried to
do that (as the original ND RFCs recommended) found significant
issues, including chicken-and-egg problems, inability to protect
multicast in the proper way, no way to authorize ND decisions, etc.
It is true that in some very limited scenarios you can actually
configure static keys (as RFC 2461bis describes), but its not clear
that this is any better than employing link layer protection for all
communications.

Suggested text replacement: Where support for secure autoconfiguration
is required, SEND [SEND] can be used.

Comment-only part:

First, I agree with Mark that the softwire work should be referenced
along with 6to4. Also, there does not appear to be any DSTM draft in
existence any more (that I can find at least). I wonder if its wise
to reference work that is not even pursued anymore, given that we
have alternative mechanisms too.

> one location may lead (or lag) the IPv6-compability of its peer (or

Typo.

[Ballot discuss]
> For secure autoconfiguration, the IPsec [IPSEC] or SEND method
> [SEND] can be used.

I would not like to recommend the use IPsec for securing
autoconfiguration. Most of the time autoconfiguration is not secured
beyond possible link layer protection. But when you need to secure it,
the use of IPsec is not really a viable option. People that tried to
do that (as the original ND RFCs recommended) found significant
issues, including chicken-and-egg problems, inability to protect
multicast in the proper way, no way to authorize ND decisions, etc.
It is true that in some very limited scenarios you can actually
configure static keys (as RFC 2461bis describes), but its not clear
that this is any better than employing link layer protection for all
communications.

Suggested text replacement: Where support for secure autoconfiguration
is required, SEND [SEND] can be used.

Comment-only part:

> one location may lead (or lag) the IPv6-compability of its peer (or

Typo.

[Ballot discuss]
This document excludes a lot of layers and functions to be considered a 'IPv6 Enterprise Network Analysis' as the title claims. Designed as a continuation in a series of operational requirements and deployment documents for IPv6 in the enterprise open by RFC 4057, it declares out of scope and leaves for future consideration key operational and fucntional aspects like network management, mobile IP, multicast and other. I could live with this, and I still believe that there is enough useful stuff in this document, but at least the title needs to be changed to reflect what the declared focus of this document really is - IP Layer 3 deployment of IPv6 in the enterprise.

[Ballot comment]
I think this document fails to meet many of it's goals. I don't think it will help an enterprise figure out how to transition to v6 - there is so many critical things it does not mention, like applications that run on hosts. I have a hard time imagining any easy way to fix it.

[Ballot discuss]
From the SecDir review by Bernard Aboba:

  Section 7.4.5 does not talk about host-based security measures.
  This will be quite important because IPv6 vulnerabilities are less
  well understood, and therefore the intrusion detection and firewall
  software may be less mature, so that a "belt and suspenders" approach
  is probably required.  Also, dual stack systems are prized by hackers
  so that root kit detection is probably a good idea as well.

Pulled from the agenda due to reference issues that need to be resolved first:

Lisa Dusseault found the following:

This draft is missing substantial references.  I can't find what               
documents are meant by [V6DEF],  [DNSV6REC], [NIS], [DHCPv4],                 
[ADDRCONF], [IPSEC] or [PRIVv6].  [NAP], [V6SEC], [DNSv6] and [DSTM]         
do show up in the references section but there are no URLs or draft           
names which makes a reader have to go hunting and guess.                       
                                                                               
It makes it rather hard to evaluate the advice in the document when           
the references are in such bad state. Would you consider asking the           
authors to fix this before we continue evaluating?


- Missing Reference: [VLAN] is mentioned on line 549, but not defined       
  - Missing Reference: [V6DEF] is mentioned on line 581, but not defined       
  - Missing Reference: [DNSV6REC] is mentioned on line 799, but not defined   
  - Missing Reference: [NIS] is mentioned on line 823, but not defined         
  - Missing Reference: [ADDRCONF] is mentioned on line 827, but not defined   
  - Missing Reference: [IPSEC] is mentioned on line 830, but not defined       
  - Missing Reference: [SEND] is mentioned on line 833, but not defined       
  - Missing Reference: [V6TUN] is mentioned on line 996, but not defined       
  - Unused Reference: [CONF] is defined on line 1054, but not referenced       
  - Unused Reference: [DHCPF] is defined on line 1057, but not referenced     
  - Unused Reference: [DHCPL] is defined on line 1061, but not referenced     
  - Unused Reference: [6TO4] is defined on line 1065, but not referenced       
  - Unused Reference: [NATPT] is defined on line 1087, but not referenced     
  - Unused Reference: [UMAN] is defined on line 1091, but not referenced       
  - Unused Reference: [ISPA] is defined on line 1095, but not referenced       
  - Unused Reference: [3GPA] is defined on line 1099, but not referenced       
  - Unused Reference: [SEC1] is defined on line 1126, but not referenced       
  - Unused Reference: [TSPB] is defined on line 1143, but not referenced       
  - Unused Reference: [NATDE] is defined on line 1146, but not referenced

[Ballot comment]
This document rules so many important things out of scope--nat used
for V4, firewalls, application issues--that it is useless in my mind.
The best I can say is that I don't think it will do any harm.

[Ballot comment]
The reference [V6DEF] is not filled in (referenced in section 5), nor is [DNSV6REC], [NIS], [DHCPv4], [ADDRCONF], [IPSEC] or [PRIVv6].  I wish the "works in progress" references had pointers (like [DNSV6]), are they not Internet Drafts?

"At the time of writing, best practice in IPv6 site address planning
is restricted due to limited wide-scale deployments."

Does this mean "At the time of writing, solid details on best practice in IPv6 address planning is restricted..."?  I  am pretty sure it doesn't mean that the applicability of best practice is limited...

PROTO Write-up

> 1.a) Have the chairs personally reviewed this version of the
> Internet Draft (ID), and in particular, do they believe this ID is
> ready to forward to the IESG for publication? Which chair is the
> WG Chair Shepherd for this document?

Yes, I believe that it is ready for publication. I will be the proto-
shepherd.

> 1.b) Has the document had adequate review from both key WG members
> and key non-WG members? Do you have any concerns about the depth
> or breadth of the reviews that have been performed?

This document has had significant and at times contentious review in
the working group. I believe that the recommendations it makes are
sound and have been accepted by the working group.

> 1.c) Do you have concerns that the document needs more review from
> a particular (broader) perspective (e.g., security, operational
> complexity, someone familiar with AAA, internationalization, XML,
> etc.)?

I could imagine interest in the Internet area. It is essentially
operational, so issues that the security area or others might come up
with are more comments on IPv6 than they are on these points.

> 1.d) Do you have any specific concerns/issues with this document
> that you believe the ADs and/or IESG should be aware of? For
> example, perhaps you are uncomfortable with certain parts of the
> document, or have concerns whether there really is a need for it.
> In any event, if your issues have been discussed in the WG and the
> WG has indicated it that it still wishes to advance the document,
> detail those concerns in the write-up

There has been significant discussion in the WG regarding the
document. At this point, I believe that the document is appropriate
and makes appropriate statements.

> 1.e) 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?

One could describe v6ops as a set of groups of people intimately
worried about specific topics among a crowd of people who mostly want
to stay in touch with what happens. As such, it is a pretty quiet
group. However, consensus exists behind this document to the extent
it can be measured.

> 1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email to the Responsible Area Director. (It should be
> separate email because this questionnaire will be entered into the
> tracker).

not to my knowledge.

> 1.g) Have the chairs verified that the document checks out against
> all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
> Boilerplate checks are not enough; this check needs to be thorough.

Yes.

> 1.h) Has the document split its references into normative and
> informative?

Yes.

> Are there normative references to IDs, where the IDs are not also
> ready for advancement or are otherwise in an unclear state?

There are several references to internet drafts. All are non-normative.

> The RFC Editor will not publish an RFC with normative references to
> IDs (will delay the publication until all such IDs are also ready
> for RFC publicatioin). If the normative references are behind,
> what is the strategy for their completion? On a related matter,
> are there normative references that are downward references, as
> described in BCP 97, RFC 3967 RFC 3967 [RFC3967]? Listing these
> supports the Area Director in the Last Call downref procedure
> specified in RFC 3967.

This has been addressed.

> 1.i) For Standards Track and BCP documents, the IESG approval
> announcement includes a write-up section with the following sections:
>
> * Technical Summary

This document analyzes the transition to IPv6 in enterprise
networks. These networks are characterized as a network that has
multiple internal links, one or more router connections, to one or
more Providers, and is managed by a network operations entity. The
analysis focuses on a base set of transition notational networks and
requirements expanded from a previous Enterprise Scenarios document.
Discussion is provided on a focused set of transition analysis
required for the enterprise to transition to IPv6, assuming a Dual-IP
layer (IPv4 and IPv6) network and node environment, within the
enterprise. Then a set of transition mechanisms are recommended for
each notational network.

> * Working Group Summary

This has been discussed in detail in the working group.

> * Protocol Quality

This does not specify a protocol.