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

["Bound, Jim" <jim.bound@hp.com>]

Hi Pekka,

Responses in line.

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola
> Sent: Monday, October 11, 2004 7:14 AM
> To: v6ops@ops.ietf.org
> Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd)
> 

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

They did yes.  Thank You.  Reflect belows mean we need to think on how
to fix or make more clear in the spec.

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

We need to add more text to sect 3 and 8.  If trivial but pivotal to the
analysis we kept them in the draft for later context and why we have
more writing to do.

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

I think we can enhance that text but don't think it wise to discuss that
which is omitted because that can cause a rathole.  Would suggest that
WG tell us what needs to be added?

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

We believe we have that covered.

What do you mean by new solution that may help?

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

We do that by the protocol in the cell but we can explain that better
for further input to see if WG believes it is correct.  Seems we need to
describe the cells better from recent input.

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

I would agree on v6 only ISPs and that really is dual stack for some
time.

But we as a team and many in this WG do believe IPv6 dominant networks
will be supported and we intend to leave that scenario and matrix cell
in the spec but we can keep discussing.  

We do need to make it clear an ISP will not be v6 only that was not our
intention either.

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

V6only apps implies a dual stack.  It should say v6 apps.  

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

Scoping for most sections is still required I agree.

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

We are addressing the enterprise and enterprise remote sites.  We need
to make that clear this section is incomplete now.  Most enterprises run
their own Internet Walmart, GM, DOD, Renault, Boeing, etc and each will
have different views and business reasons for deploying IPv6.  Again
one-size-does-not-fit-all.

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

Good catch.

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

Not sure I agree.  V4 or v6 transport is a choice we assume dual stacks?

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

Agree.

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

Agree.

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

I think first we need to provide support for all possibilities and we
cannot require users to deploy our view, only provide mechanisms for
scenarios we believe we have heard.  And there are enough users want to
run IPv6 dominant subnets immediately and this does not mean nor to we
imply v6 only anything if so we need to fix it.

We should not be doing business cases for IPv6 in the IETF.  That is
what will determine how transition is done in the market.  Out of scope
for the IETF.


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

We can do that but point is decap via Tunnel Broker at remote site is
something we have heard. I agree with all the security concerns when
Enterprise is going to public Internet.

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

We have heard it is a requirement and it is an option.

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

Good point we need to discuss this as authors given the NAT-PT
discussion.  One issue is if the dual stack node cannot get a required
routable address to communcate with the legacy IPv4 only stack node.

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

No DSTM just provides address on the link or subnet.  Nomenclature
positioning needs work.

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

That was old AIIH proprosal but that is not being suggested at all.

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

This is a bug.  The v4 is encaped in v6 to the edge, and we can define
the edge better.

Good catch.

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

Not really it is an example of a real network reinforcing the enterprise
and the objective of the appendix.

> 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?]

I think so too but we ran out of writing time for last draft :--)

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

We want to talk among authors on that one I can't comment on this other
than from the recent input it might make it more clear that this spec is
about Layer 3 with a few exceptions.

> 
> ==> s/Analysis/Transition Analysis/ ?

Thanks.

> 
> Abstract and introduction say:
> 
>  This document analyzes the transition to IPv6 in enterprise 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?

I think so yes.

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

Will fix.

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

Need to reflect more and thanks.

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

Agreed.

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

OK needs reflection yes.

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

Needs reflection yes.

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

All of the above have to be part of our analysis but how we present that
is TBD.

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

This is a huge bug we need to fix this.  Good catch.  This was mean't to
say these are next level common transition issues for deployment all our
v6ops docs have not addressed so lets not pick on enterprise analysis.  

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

Yes.

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

Me to I defer to my co-authors :--)

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

Hmmmm to some degree yes but we don't want to own that one in this spec
we may need some WG help on this one.

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

I agree and we need more reflection ok.

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

Yikes.  I don't think so nor that auto transtion can ever achieve
consensus as its an implementation issue. But if WG goes forward so will
we but I don't think so.  As my input.

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

I agree.

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

I want to fight for an exception on this ok.  So I will get ready to
ask.  I understand but these folks names all should be listed.  

> 
> ==> 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?

Thanks we need to address that process.

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

Thanks.

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

Gee wizzzzzzzzzzzzzzz  ok.

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

Will reflect on this.

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

Agreed.

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

OK.

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

Need to reflect.

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

That is better yes.

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

Yep.

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

Will reflect.

> 
>                                                               
>                                                               
>                       
>  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? :-)

Yes.

> 
>  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" ;-)

Thanks
/jim