Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd)

From: "Bound, Jim" <[email-masked]>
Date: Thu, 7 Oct 2004 13:33:12 -0400

Hi Jonne,

Sorry for late response I am traveling yet again.  I agree with what Tim
stated and also the team is ready to go. Before we solidified the
recommendations we wanted the WG to respond as Tim pointed out.  We can
move forward  but that has more risk.  I can present our status and
results at D.C and suggest that I should if you and Pekka agree.  But
let us know ok.

Seems like we should move forward.  I suggest we give WG till next
Tuesday to respond ok?  Then we have no choice but to go to next rev.
Its to bad we just lost at least 2 weeks from no input of stagnation?

Thanks
/jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Soininen Jonne 
> (Nokia-NET/Helsinki)
> Sent: Thursday, October 07, 2004 8:33 AM
> To: [email-masked]
> Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd)
> 
> Hello,
> 
> <Chair hat on>
> I'm wondering why there are no comments to this draft. To 
> kick-off the discussion I'm going to provide some of my own. 
> However, please, comment the draft! We cannot move forward if 
> people don't comment!
> <Chair hat off>
> 
> I'm not going to comment much on the details. As it is the 
> first version, I'm just trying to express my opinion on the 
> general direction of the draft.
> 
> First of all, there is a lot of information in the draft 
> about how the transition/deployment of IPv6 in enterprise 
> environment is to be done.
> However, the conclusions seem not to be clearly derivable 
> from the text.
> I think the goal of the document is to have clear conclusions 
> what is expected from the IETF to be done (nothing - 
> everything is already done, requirements for transition 
> protocols/mechanisms, identifying the protocol needed). 
> 
> I think this is somewhat in the document, but not clearly 
> enough. So, what I would like to see is more clearly the link 
> between the actual text of the document and the conclusions 
> in the section 8. At least to me it is not clear how the 
> conclusions have been reached.
> 
> Cheers,
> 
> Jonne.
> On Mon, 2004-09-27 at 12:29, ext Pekka Savola wrote:
> > Folks,
> > 
> > (co-chair hat on)
> > 
> > There haven't been any reviews on the list.  That's not 
> good.  We need 
> > the reviews to make this go forward.  Otherwise we cannot 
> go forward 
> > with this, and we cannot go forward with the transition 
> mechanisms for 
> > the enterprises.
> > 
> > PLEASE provide feedback ASAP!
> > 
> > (co-chair hat off)
> > 
> > ---------- Forwarded message ----------
> > Date: Sat, 18 Sep 2004 21:24:32 +0300 (EEST)
> > From: Pekka Savola <[email-masked]>
> > To: [email-masked]
> > Subject: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt
> > 
> > Hi,
> > 
> > (co-chair hat on)
> > 
> > This is the initial draft on Enterprise network analysis, 
> and is still 
> > being improved.  We need input from the WG to make it 
> better.  Please 
> > read and comment ASAP, preferably within a week.  We hope 
> to get this 
> > in the shape for WG last call reasonably soon.
> > 
> > Again, please send feedback.  This is very important work!
> > 
> > (hat off)
> > 
> > 
> > On Thu, 16 Sep 2004 [email-masked] wrote:
> > > 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		: IPv6 Enterprise Network Analysis
> > > 	Author(s)	: J. Bound, et al.
> > > 	Filename	: draft-ietf-v6ops-ent-analysis-00.txt
> > > 	Pages		: 30
> > > 	Date		: 2004-9-16
> > > 	
> > > 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 will focus on a base set of transition units and  
> > > requirements expanded from a previous Enterprise Scenarios  
> > > document, and will depict a set of components and transition  
> > > methods required for the enterprise to transition to IPv6 within  
> > > each scenario and then common to all scenarios.
> > > 
> > > A URL for this Internet-Draft is:
> > > 
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-00
> > > .txt
> > [...]
> > 
> --
> Jonne Soininen
> Nokia
> 
> Tel: +358 40 527 46 34
> E-mail: [email-masked]
> 
>

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Thu, 07 Oct 2004 23:21:54 +0300

Jim,

your proposal sounds like a plan. If the WG decides to remain silent
until next week, please produce another draft without comments. I guess,
the WG will speak up sooner or later! 

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34

---

From: Pekka Savola <[email-masked]>
Date: Mon, 11 Oct 2004 14:14:26 +0300 (EEST)

Hi,

> the WG will speak up sooner or later! 

I had been waiting for comments from the WG participants, but we 
haven't yet had much much of that..

Below are my personal comments.  I agree that the document needs to 
continue spinning forward.  There are many issues that still need 
fleshing out even under this restricted applicability.

In short, I think the doc is a good start, but obviously as all
initial documents, can always find a room for improvement.  Hopefully
my comments below help in that.

substantial
-----------

1) 
 1.a) the matrix in section 3 (and sect 8) appears to be out of sync from the
description of section 3 (see below for 'v6 to v4'), for example because the
text says trivial scenarios have been removed, but matrix lines 1,2,12, and 13
(at least) are extremely trivial.  What has happened?

 1.b) Further than that, one thing I'd like to see is slightly more text (if
that's not too difficult to manage) describing as precisely as reasonable
how the table has been 'derived', in a manner that the reader would be able
to follow which combinations have been omitted and due to what reasons. 
That would allow one to better analyze that all the cases have been dealt
with (in one manner or another).

Please also remember that even the trivial tunneling/translation scenarios
will need to be described if we need a (new) solution to them.

 1.c) you may need to end up having to define the columns of the matrix
carefully.  In particular 'Host X network' (I read it as "the enterprise
network originating the packets") has at least one ambiguity.  How do you
represent the fact that the first-hop link of a dual-stack node supports
only one protocol version, but further down the enterprise network both
protocols are supported ?

 1.d) there also seem to be some scenarios which are either too far in
the future or easily worked around which might be decreed out of scope.  For
the former, consider the cases of v6-only ISPs -- I don't think these are
worth the energy at this point of time.  Or do you refer to *dual-stack*
ISPs who are offering only v6 services (and provide translation/tunneling
for v4 legacy)?  For the latter, consider the scenario 4, i.e.,
v6-only application run on a dual-stack host, towards an IPv4-only
application.  I mean, what would the point of creating v6-only application
which needs to talk to v4-only application, because doing such would nullify
all the benefits of IPv6 -- couldn't one just say that one should do a
dual-stack app in that case?

[IMHO, v6-only apps should never be used if that necessitated the
translation to v4, because doing so would nullify the usefulness of v6-only
app to begin with, or requiring embedding a lot of v4 hacks in the
translator -- both would seem like non-starters to me]

2) section 4.5 and 7.5.2 describe some approaches to remote IPv6 access
support, but Introduction ruled IPv6 VPN's as out of scope.  These could be
seen as contradictory (but maybe the latter referred to v6-in-v6 VPNs, I
don't know).. maybe it needs to be clarified what's in scope and what's not?

(Section 4.5 is not clear whether you're addressing the 'branch office' or
'home user' case.. probably the latter?)

3) section 4.1 says that ULAs are not considered or advocated in this doc,
while 7.3.2 says they should not be used.  These appear to be conflicting
statements.  I think it'd be useful to mention ULAs, state that they are not
*necessary* but could be used under specific conditions, and possibly to
point to another document to come [on NAT-PT/RFC1918 alternatives].

4)
7.4.1 IPv6 DNS
                                                                                                                                                  
 The enterprise site should deploy a DNS service that is capable of
 both serving IPv6 DNS records (of the AAAA format, see RFC????) and
 of communicating over IPv6 transport.
                                                                                                                                                  
 Specific IPv6 DNS issues are reported in [DNSV6].

==> I think it would be useful to make it clearer here that while the v6
transport is nice, it's in no way requirement for anything, except for
deploying v6-only nodes.

(For example, in our enterprises, we haven't been able to field v6 transport
resolver support in 2-3 years due to a number of reasons, but that hasn't
stopped us from deploying v6 -- the document should (IMHO) give as few as
possible requirements for "moving forward" with IPv6.

The similar occurs in 7.4.3:

A stateless configured node wishing to gain other configuration
 information (e.g. DNS, NTP servers) will likely need a Stateless
 DHCPv6 service available.

, where this doesn't clearly identify that these are not strictly necessary
for dual-stack systems.. because they are already configured using v4
protocols and means.  Just to make it clearer that these are not a strict
requirement for v6 deployment..

5) a few further comments on the matrix in section 8:

 ======================================================================
   |    IPv6    |       |        |       |    IPv6    |IPv6 Host Tunnel
 3 |    ----    | IPv4  |Dual IP |Dual IP|    ----    |(Brokered atISP)
   |    Dual    |       |        |       |    IPv6    |

==> isn't this a conflict with this statement in Introduction:

 We are also assuming that the enterprise deployment is one being
 undertaken by the network administration team, i.e. this document
 is not discussing the case of an individual user gaining IPv6
 connectivity (to some external IPv6 provider) from within an
 enterprise network.

(i.e., it seems as if there is zero v6 support in the home enterprise, so
the host gets it from the ISP-- but this was considered out of scope...)

   |    IPv6    |       |        |       |IPv4    IPv4|Translation on
 4 |    ----    | IPv4  |Dual IP |Dual IP|---- or ----|local IPv6
   |    Dual    |       |        |       |IPv4    Dual|domain

==> as said, IMHO this nullifies the usefulness of creating v6-only
applications so wouldn't it be better to just require such apps to support
v4 as well?  (there may be a couple of rare exceptions to this, like 3GPP
IMS, but those are another story)

   |    IPv6    |       |        |       |    IPv6    |IPv6 Host Tunnel
 5 |    ----    | IPv4  |  IPv4  |Dual IP|    ----    |(Brokered at
   |    Dual    |       |        |       |    IPv6    |Net2)

==> this would appear to be case where the host tunnel is brokered across
the Internet.  What reason would Net2 have for providing this to other
enterprises?  Do you have specific assumptions about their relations?

   |IPv6    IPv6|Dual IP|        |Dual IP|IPv6    IPv6|Site-to-Site
 6 |---- or ----|  or   |  IPv4  |  or   |---- or ----|Tunnel|
   |IPv6    Dual|v6 only|        |v6 only|IPv6    Dual|(Brokered?)

==> wouldn't this be creating something like 'v6 6bone mess' (especially if
sites are 'v6 only', which we all probably want to avoid?  I mean, is there
a specific problem in the current approach, i.e., the enterprises which want
to connect other v6 enterprises to get v6 ISPs which are globally connected
throughout the Internet ?

   |    IPv6    |Dual IP| IPv4,  |       |    IPv4    |Translation on
 7 |    ----    |  or   | IPv6 or| IPv4  |    ----    |local IPv6
   |    IPv6    |v6 only|Dual IP |       |    IPv4    |domain

==> isn't this a regular 'why don't you just run dual-stack instead' argument ?

   |    Dual    |       |        |       |    IPv4    |DSTM for
 10|    ----    |Dual IP| v6 Only| IPv4  |    ----    |v4 thru v6
   |    Dual    |       |        |       |    IPv4    |
 ======================================================================
   |    Dual    |       |        |       |    IPv4    |DSTM for
 11|    ----    |v6 only| v6 only| IPv4  |    ----    |v4 thru v6
   |    Dual    |       |        |       |    IPv4    |

==> you are proposing to run DSTM over Internet, right?  I don't think
it was ever (except for separate DSTM VPN I-D) designed to run like
that, and it would likely have significant amount of security issues.  
I also don't see the element in the middle which would support
dual-stack?!?  i.e., how does v6 only site talk through v6-only ISP to
a v4-only site, for example?  Also, (repeating from matrix line 5
above), what would be the justification for Net2 to provide such
Interdomain service ?

6) I'm having slight problems, at least yet, at seeing what is the role of
appendix B in this document.   This seems to be partially duplicating the
text from enterprise scenarios, or..?  It also has some specific discussion
and good analysis.  Should some parts of this be in the body, in a separate
document, or..?  [also note, the text is rather unreadable because some
lines are wrapped oddly -- are you using good tools e.g. xml2rfc for
editing?]

semi-substantial
----------------

                  IPv6 Enterprise Network Analysis

==> given that the document restricts itself to (mainly) L3 considerations,
would there be simple ways to try to reflect that somehow in the title of
the draft and intro/abstract?  For example insert 'connectivity' there?  Not
a big issue.

==> s/Analysis/Transition Analysis/ ?

Abstract and introduction say:

 networks.

==> should one say "to using IPv6" instead, given that the focus of the
document is not go all the way to the get to IPv6(-only), but the first step
being providing the IPv6 capability?

...

 As an example, Scenario 1 is an IPv6 application trying to
 establish a communications exchange with a destination v4 only
 application.

==> uhh??  Not by the matrix at least -- maybe some matrix lines were
removed? (see also substantial issue 1 above)

Then, the IPv6
 intranet communication will not be efficient, as it will require
 all the traffic to be forwarded by the IPv4 infrastructure to the
 Tunnel-End-Point located at the ISP. This could be acceptable if
 the IPv6 applications do not require intranet communication at all,
 for example in the case the application server that is located
 outside of the enterprise network, or in other networks of the same
 enterprise.

==> this section discusses only efficiency (AFAICS), but a major factor
whether to pass internal traffic to the ISP (and back) is about trust.  For
most enterprises I know (and all the big ones, I'd suspect), they don't want
to give external folks any chance of intercepting internal communications,
which might or might not be encrypted, and might or might not contain
classified information.

If the tunnel end-point is at the ISP, there is no way to prevent this. 
Thus I can imagine no scenario, where an enterprise (which would have more
than a couple of employees, or operate w/ encryption) would want to put the
end-point out of it's own trusted network.

This also becomes an issues of redundancy; if the communications to the ISP
breaks down e.g., temporarily, is the internal traffic affected?  Having
internal tunnel endpoint would ensure that one would be able to continue
without disruptions.

........

5.2  Manual versus Autoconfigured

 If the number of nodes to be using IPv6 is reduced, an option is to
 use statically configured tunnels.
                                                                                                                                                  
 However, in general automatic configured tunnels will be preferred.
                                                                                                                                                  
 Section 5 doesn't yet discuss pros and cons of connecting sparse
 nodes, nor management/security issues.  We need to add that in -01.

==> this isn't complete yet, so I don't know if you intended to discuss
these or not but here are a couple of potential considerations:

 - are you considering just autoconfigured set-up ('assisted tunneling' or
'zero-conf tunneling'), or also "direct tunneling" ?
 - are you considering whether there are internal NATs in the enterprise or
not (I don't personally know whether this is typical or not) ?
 - do you consider whether there are multiple boxes or just one (and if
multiple, how are would they be distributed [e.g., geographically])
   i.e., the number of users?

.......

7.4 Phase 2: Deploying generic basic service components

 Most of these are discussed in Section 4 of [BSCN].   Here we
 comment on those aspects that we believe are in scope for this
 analysis document. Thus we have not included network management,
 multihoming, multicast or application transition analysis here, but
 these aspects should be addressed in Phase 2.

==> I may be misunderstanding the last line, but isn't that saying that
section 7.4 should be addressing this, or are you referring to the "next
round" of enterprise evaluation (beyond the basic concepts) ?

...........

....

 For secure autoconfiguration, the SEND protocol is defined (now at
 RFC????).

==> because deploying SEND is not necessarily quite as trivial as this,
maybe a placeholder should be put here, like 'The best practices for
deploying the necessary certificates need to be analyzed.'

........

 Hosts may also generate or request IPv6 Privacy Addresses
 (RFC3041);  there is support for DHCPv6 to assign privacy addresses
 to nodes in managed environments.

==> is there actually any justification for using RFC3041 in enterprise
environments?  Should one put such a doubt here if not?  Personally, I'm
having trouble figuring out the actual problem...

....

Use of [NAT-PT] is discouraged [cite the I-D on this?].  A
 recommended solution is the use of ALGs.  Many applications
 naturally have an ALG behavior, and can be used to offer access for
 "legacy" IPv4 services such as SMTP (dual-stack email server, see
 [cite I-D, by Alain I think?]) or HTTP (a dual-stack web cache),
 and are already operated by many enterprise sites. By dual-stacking
 the servers, an IPv6 only node can reach an external IPv4-only web
 site (for example) via the proxy without any additional (Layer 3 or
 4) translation being required.

==> it would be worth mentioning (at least as a problem, if not further
discussed) in a new paragraph how one would configure such proxies or
translators on the v6-only nodes.  Manually?  Using yet-to-be-defined DHCPv6
options?  Using unspecified means?

 Such an aid may be either a tunnel broker [TBRK], ideally one that
 supports operation through an IPv4 NAT, or a 6to4 relay [6TO4].  If
 a 6to4 relay is offered, the site should be aware of security
 issues with operating 6to4 relays [cite ref?].

==> are you referring to the 6to4 relay usage in a manner where the
enterprise would provide a 'private' 6to4 relay, just for its own users who
would need to know its v4 address, and manually configure it on their
laptops (w/ using public addresses)?  Note that there is no provision for
access control here.  Considering how common the NATs are, this seems like
something that doesn't have sufficient "return value" for the enterprise,
considering that there are plenty of free relays reachable through the
anycast prefix.

 There is ongoing work on auto-transition and assisted tunneling
 tools that may also be applicable as remote access aids [cite
 refs?].

==> possibly, but please note that most of those focus on the scenario where
the access is provided by the first-hop ISP.  What you're looking for is
something like assited tunneling registered mode ('TSP') or v6-supporting
L2TP (which is not a necessarily a big problem, as PPP supports v6
trivially).

procedural
----------

==> there is one author too many (6 > 5).  If it is not possible to reduce
the number of authors, the alternative would be just listing the editor in
the front page, and the authors in the contact information or contributors.

==> there are a lot of documents in 'normative references'.  These are meant
to be documents which are required to be read to understand the document.
Please note that this doc cannot be published until all of these are also
published.  Is that intentional?  Maybe some shuffling around would be
warranted?

editorial
---------

==> there are quite a few references with 'RFC????' or the like -- these
should be filled in (naturally ;-), and maybe put in as informative
references explicitly. (Also a mention of I-D in 7.4.6, that would be
draft-motonori-dualstack-smtp-requirement-01.txt)

==> Introduction and Abstract use the term 'Provider' before it's defined,
and as such, it isn't clear to the reader that you refer to the ISP with it. 

Two possible fixes:
 1) rename Provider to ISP (because the terminology requires providing connectivity
in any case, so this looks pretty close to ISP to me), or
 2) expand Provider to ISP in abstract/introduction.

...

 The audience for this document is the enterprise network team
 considering deployment of IPv6.  The document will be useful for
 enterprise teams that will have to determine the IPv6 transition
 strategy for their enterprise.

==> there appears to be some overlap with these sentences ?

 The enterprise analysis will begin by describing a matrix tool to
 be used to portray the different IPv4 and IPv6 possibilities for
 deployment. The first column (Application/Host 1 OS) represents the
 IP-capability offered by the node that originates IP packets.  The
 second to last column (Application/Host 2 OS) represents the IP-
 capability offered by the node that terminates the IP packet.  In
 between are three columns that represent the IP-capability of
 typical networks traversed by the packet, including an originating
 host network (Host 1 Network),Service Provider Network and
 Destination Host Network (Host 2 Network). Each row (1 through 13)
 is one possible scenario and the final column shows the recommended
 transition mechanism to use for that particular scenario.

==> in the matrix in section 3, there it's the last column. (This also
applies in the text in section 3)

==> actually, I think the discussion here is slightly out of place, as it's
already there in section 3 (where it's better placed).  I'd consider just
summarizing this paragraph here to one or two sentences, and referring to
fuller description in section 3.

 IPv6 only          - A node or network capable of supporting only
                      IPv6.  This does not imply an IPv6 only
                      stack, in this document.

==> I find the last sentence slightly confusing, maybe it would better read
like 'In this document, a dual-stack node which has disabled IPv4 stack is
also considered IPv6 only.'

Many router platforms can tag multiple VLAN IDs on a single physical
interface based on the subnet/link the packet is destined for

==> 'Many' ?  Are there platforms which *can't* do it?  I'd be surprised :). 
Maybe just remove 'Many' or replace with 'Practically all'.

The parallel infrastructure would only ever be seen as an interim
step towards a full dual-stack deployment on a unified
infrastructure.

==> could 'would only ever be seen' be reworded?  That seems like a complex
structure of words for us foreigners..

 The upstream provider could have already deployed some IPv6
 service, either native IPv6 in its backbone or in the access
 network, or a combination of both. Also, or alternatively, could
 have deployed one or several transition mechanisms based upon
 tunnels, for example in the case where the access network doesn't
 support IPv6. In this case, the enterprise could decide to use
 those available transition services from the ISP. However, this
 will usually mean that the each of the different nodes in the
 network will have their own IPv6-in-IPv4 tunnel. Then, the IPv6
 intranet communication will not be efficient, as it will require
 all the traffic to be forwarded by the IPv4 infrastructure to the
 Tunnel-End-Point located at the ISP. This could be acceptable if
 the IPv6 applications do not require intranet communication at all,
 for example in the case the application server that is located
 outside of the enterprise network, or in other networks of the same
 enterprise.

==> s/could/it could/ ?
==> could this paragraph be broken into two (or three), making it more
digestible? :-)

 The enterprise could also decide to deploy its own transition box
 and possibly collocate it adjacent to the border router that

==> s/collo/co-lo/

 IPv6 communications between IPv6 nodes will use IPv6 to
 communicate.

==> sounds like a no-op ?

Author's Address

==> make that "Authors' Addresses" ;-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: [email-masked]
Date: Mon, 11 Oct 2004 08:49:24 -0400 (EDT)

> ... [Section 5.1]

I agree this is more about trust than efficiency, and I would suggest, at
a minimum, deleting:

", or in other networks of the same enterprise"

Also, it is often about weak authentication on internal networks
(intranets) as much as about intercepted message contents.

It's likely preferable to use the word "proprietary" rather than
"classified."

Regards, Richard

---

From: Tim Chown <[email-masked]>
Date: Fri, 15 Oct 2004 16:00:13 +0100

> substantial

I think the doc needs to clarify 
a) why the cases that are being focused on are being focused on
b) show that no corner cases are being overlooked that may require additional
   transition functionality not yet available.

> protocols are supported ?

A full matrix of posisbilities is big :)
 
> the future or easily worked around which might be decreed out of scope. 

On the contrary I think 4-in-6 tunnelling must be considered now.  It is
the end-game for some, for others it's on the near term radar.  But more
importantly it would be nice to have solutions that cater for both from
the outset, rather than discovering something in 2-3 years that we could
have thought about now.

> don't know).. maybe it needs to be clarified what's in scope and what's not?

Remote access doesn't imply VPN for everyone.  My view on 4.5 and 7.5.2 is
providing IPv6 access in general, i.e. where the user's point-of-attachment
ISP offers no IPv6 service, but the user's home ISP (enterprise) can (e.g.
a broker or 6to4 relay).

> 'home user' case.. probably the latter?)

By "site" I'd include branch offices.  For 4.5 I mean a user at home, or
a hotspot, or any case as per my text immediately above.
 
> point to another document to come [on NAT-PT/RFC1918 alternatives].

Hmm, I don't remember writing that, good spot :)  I suggest removing the
reference to ULAs in 7.3.2.

> transport is nice, it's in no way requirement for anything, except for

OK, so say

"The enterprise site should deploy a DNS service that is capable of
 serving IPv6 DNS records (of the AAAA format, see RFC????) to facilitate
 DNS lookups of IPv6 addresses for nodes.   Where IPv6-only nodes are
 deployed on site, the DNS server(s) should be capable of communicating 
 over IPv6 transport.  It is thus prudent that the site's DNS servers
 should be planned to be dual-stack."

> possible requirements for "moving forward" with IPv6.

OK, well, we run local dual-stack resolvers, and also put these in the
global DNS.   We're deploying dual-stack to facilitate the easy deployment
of IPv6 only nodes in due course.

> requirement for v6 deployment..

So "An IPv6-only stateless configured..."

Also we should state (if the ent team agrees) that a goal of dual-stack
everywhere (Sect.4) is to prepare for v6 only devices to be added easily,
thus all key services (DNS, NTP, etc) should be available over v6 transport.
 
> lines are wrapped oddly -- are you using good tools e.g. xml2rfc for

I think we could integrate Appendix B's thinking into the main text?  But
that's a big chunk of work... 
 
> the draft and intro/abstract?  For example insert 'connectivity' there?  Not

Right, but the ISP analysis also focuses on L3, as does unmanaged, and they
have a similar title?

This is also why we consider L3 and only basic services (DNS), and not VPNs
etc in the doc.
 
> round" of enterprise evaluation (beyond the basic concepts) ?

In 7.4.
 
> deploying the necessary certificates need to be analyzed.'

The above line was only ever meant to be such a thing, so any wording is OK
as long as it makes the point clear.
 
> having trouble figuring out the actual problem...

It is a currently valid RFC that should be considered in host address
configuration, hence it's in 7.4.3.
 
> options?  Using unspecified means?

I agree it should be included.  Not sure on exact wording.
 
> considering that there are plenty of free relays reachable through the

Yes, manually configured.  We do this now and it is used.   Up to the user
to choose that (or whoever admins their machine) or to use a "near" relay
offered by some other ISP.
 
> published.  Is that intentional?  Maybe some shuffling around would be

Good point :) 
 
Thanks for the feedback!

-- 
Tim