[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WGLC ent-analysis-03
Hi Pekka,
Others are responding to DSTM below are comments on other points for the
work.
> Thank you for additional "textual" discussion of the matrix.
> IMHO it is
> very useful. While I am skeptic about the matrix approach,
> modifying that
> goes beyond the point of diminishing returns. In general, I think the
> document is in a very good shape, though Section 8 (which is a recent
> addition) still requires wider review.
Thanks.
> 1) I still think appendix is a bit inappropriate for this document,
> and it be removed from this doc. (I did not review it at length.)
Authors feel it is important to keep and we have not seen any pain or
issue within the working group keeping an appendix.
>
> 2) [see separate mail on app vs network-driven]
Being responded to by others in the community and a few of the other
authors.
>
> 3) [see separate mail on DSTM]
Yep.
>
> 4)
>
> 8.2 Recognizing Application incompatibilities
> [...]
>
> This leads us to the third theme represented by Scenario E and G,
> i.e. incompatible applications communicating across a homogenous
> network. Translation is an obvious solution, but not recommended
> except for legacy devices at the network edge which cannot or never
> will be upgraded to IPv6. A more scaleable solution would be to
> use an Application Layer Gateways (ALG) between the incompatible
> hosts.
>
> ==> I don't understand this theme. In all scenarios from E
> to J, it seems
> that the application version between the two endpoints is
> different. Is this what you meant in the matrix? I fail to
> see how that
> kind of situation can be addressed by tunneling. (I don't
> think that's what
> you're implying, but rather that there are typos in the
> matrix or I don't
> understand its basic assumptions.)
We mean incompatible networks in the matrix we can word smith this yes.
>
> 5)
>
> Having IPv6 applications on a Dual-IP host on a v4-only network
> lets you use ISATAP [ISTP] or Teredo [TRDO] to tunnel to a v6 end
> service. ISATAP [ISTP] can be used to provide end node IPv6
> connectivity from nodes on an isolated IPv4 network, through the
> use of automatic tunneling of IPv6 in IPv4.
>
> Enterprise architects should consider providing a Tunnel Broker
> [TBRK, TSPB] as a cost effective service to local users or
> applications. Tunnel Brokers can be used to provide tunnel setup
> for an enterprise using manual configured tunnels, 6to4, or DSTM.
> Tunnel Brokers can automate the use of tunnels across an enterprise
> deploying IPv6.
>
> ==> I think these paragraphs provide a bit too little
> context. The first
> paragraph also seems to introduce ISATAP and Teredo with
> different manner
> compared to the tunnel broker. Here's my attempt at rewording:
>
> Having IPv6 applications on a Dual-IP host on a v4-only network
> requires some form of tunneling. Where configured tunnels [BCNF]
> are not sufficient, a more automatic solution may be appropriate.
> Typical solutions include a tunnel broker [TBRK, TSPB],
> ISATAP [ISTP],
> or even Teredo [TRDO].
>
> (there is more analysis on the tradeoffs of the solutions
> later, so I don't
> think it's necessary to do that here.)
I don't have problem with this and will suggest to authors. thanks. One
author does not believe TRDO should be used.
>
> 6)
>
> 11.1 Normative References
>
>
> There are no normative references in this document to depict
> correct protocol operation. This document is an analysis technical
> effort not a operative or protocol specification.
Personally I agree. Will discuss with authors.
>
> ==> while the "Normative References" section is not meant to
> be normative in
> that sense, in documents like this, it is typically intended
> to include
> those documents which are:
> 1) required to be understood for understanding this specification,
> 2) are work-in-progress and significantly discussed, and the details
> mentioned in this document could change before the other drafts
> are complete, so we require that those docs must be published
> as RFCs before this is published as an RFC, or
> 3) other documents which are appropriate for understanding this one
> which should be published as RFCs before this draft is done.
>
> In that light, I'd suggest moving some documents over to the Normative
> references:
>
> BSCN, 6TO4, TRDO, BCNF (note, I'd also refer to
> draft-ietf-v6ops-mech-v2
> instead/in addition because it's replacing BCNF)
Will discuss ok.
>
> Moving these would not hurt:
>
> CONF, DHCPF, DHCPL, 6TUN, TBRK, ALLOC
>
> These might also be candidates for moving:
>
> DNSV6, APPS, NAP, V6SEC, NATDE
>
> These could probably be removed completely:
>
> SEC1 (not referred), OSPF, BGP4, ISIS, RIPng
Will discuss.
> almost substantial
> ------------------
>
> - The second column represents the IP-capability of the
> host network wherein the node originated the packet.
> (Host 1 Network)
>
> ==> I'm sorry, but I'm still not 100% sure on what you mean here.
> Do you mean:
>
> a) "the network where the host plugs into" (i.e., the
> subnet), where the
> enterprise might have different network elements, or
Yes the above.
>
> b) "the least common denominator in the whole enterprise network".
>
> Let me try to take an example from scenario A:
>
> | IPv6 | |Dual IP | | IPv6 |
> A | ---- | IPv4 | or |Dual IP| ---- |
> | Dual IP | | IPv4 | | Dual IP |
>
>
> Could network 1 address this problem (if the service
> provider is dual-IP)
> by configuring a manual tunnel from the host 1 to the
> enterprises border
> router (assumption a) above) or some other component? (With
> interpretation
> b) above, this wouldn't be possible because there wouldn't be any IPv6
> connectivity, v6-capable routers, etc. from the enterprise to
> the ISP.)
>
> This is important point to get clarified, though it's not as
> critical as
> before because the recommendations for solutions are no longer
> strongly tied to the scenarios.
We can make this clearer I believe per your mail.
>
> ........
>
> If the number of nodes to be using IPv6 is reduced, another option
> is to use statically configured tunnels. However automatically
> configured tunnels are generally preferred.
>
> ==> I'm not sure if I agree completely with this phrasing;
> I'd recommend
> (unless other considerations are on the table, such as the
> dynamicity/nomadicity of nodes/tunnels) using static tunnels
> when the number
> of tunnels is low. I would suggest below (though I would not
> object to
> spelling out the different tradeoffs further):
>
> If the number of nodes to be using IPv6 is low, the first option
> is to use statically configured tunnels. However, automatically
> configured tunnels may be preferable especially if the number is
> higher.
Personally I like this wording and will suggest to authors.
>
> .......
>
> A stateless configured node wishing to gain other configuration
> information (e.g. DNS, NTP servers) will likely need a Stateful
> DHCPv6 [DHCPv6] service available.
>
> ==> I'm not sure if this is a typo or is I disagree: "other
> configuration"
> can very well obtained from a _stateless_ DHCPv6 service. I
> think it's also
> important to point out, somewhere, that you don't need to config v6
> infortmation (at least at start) if you don't want to. Suggest:
>
> A stateless configured node wishing to gain other IPv6 configuration
> information (e.g. DNS, NTP servers) will likely need at least
> stateless DHCPv6 [DHCPL] service. In dual-IP networks,
> some enterprises
> may also choose to only distribute configuration information using
> DHCPv4.
I think we disagree many enterprises mean they want to use stateless for
addressing and use dhcpv6 stateful for all other parameters. The
assumption because a node uses stateless for addresses and not use
stateful for other configuration is invalid from our input of the users
and operators in enterprises and most enterprises will not use stateless
for initial deployment.
>
> ....
>
> 7.4.5 Security
>
> ==> I think an important pointer to add at the end of this
> section would be
> something like:
>
> Specifically, the firewall policies must be configured
> appropriately
> especially with regard to ICMPv6 [ICMPFIL]. Blocking all
> ICMP messages,
> as has often been done with IPv4 with disastrous effects
> on, e.g., PMTUD,
> must be avoided.
>
> (where ICMPFIL could be an informative ref to elwyn and janos' draft.)
We can discuss there are many many issues for security for any
transition but this one may rise to the importance of stating. Will
discuss.
>
> ....
>
> Manual Configured Tunnels for IPv6 [BCNF] is a useful mechanism to
> develop a test network in the enterprise, but will not scale well
> for a complete implementation of an IPv6 network. Manual Configured
> Tunnels for IPv6 is an IETF Proposed Standard.
>
> ==> I think this deserves more text on which scenarios or
> cases it doesn't
> scale to be fair. For example,
>
> Manual Configured Tunnels for IPv6 [BCNF] is a useful mechanism for
> tunneling between network segments, but has scalability limitations if
> applied to a large number of host-based tunnels, for example
> in scenarios A
> or C. Manual Configured Tunnels for IPv6 is an IETF Proposed
> Standard.
We want to keep this document small we will discuss it is a tradeoff and
we assume the user reads RFC 4057. We relayed this to the WG at
Minneapolis and had consensus we did not have to overstate comparisons
as you suggest so we are following that consensus.
>
> ....
>
> 6to4 [6t4] is a useful tunneling mechanism for deployment if the
> enterprise has not obtained a native IPv6 prefix from their
> provider. 6to4 is an IETF Proposed Standard.
>
> ==> while I don't have strong qualms with this text, I think
> it may mislead
> the network admin to think 6to4 is a good replacement for a real IPv6
> prefix. It isn't, due to its unpredictability especially with "return
> routing" scenarios. Therefore, I'd suggest adding a bit more
> warning here,
> for example add "Due to the unpredicatability of "return
> path", it may not
> be suitable for production use" as a second last paragraph.
Yes and it also can be a security breach too by internal users entering
the network who did not mean harm actually.
>
> ....
>
> NAT-PT [NATPT] can be useful when there is no other means to access
> an IPv4 node behind a NAT network that only has a private address.
> But, it is recommended that the enterprise also look at the ability
> to provide access to that IPv4 node using a Proxy or Application
> Layer Gateway as discussed in Section 8.3. NAT-PT is an IETF
> Proposed Standard.
>
> ==> please also refer to the applicability statement and
> state that it is
> being reclassified to experimental.
Will do.
>
> ISATAP [ISTP] is a useful tunneling mechanism when the enterprise
> has deployed IPv6, and there are particpating nodes for the IPv6
> deployment that exist on IPv4 networks. ISATAP is being submitted as
> an IETF Experimental RFC.
>
> ==> the last sentence is not pedantically correct, I believe;
> RFCs that are submitted through the RFC-editor are not "IETF"
> RFCs per se. I suggest: "ISATAP has been submitted as an individual
> submission to the RFC editor for Experimenal RFC" or
> something like that.
> (similar applies to the other mechanisms.) (also s/partic/partici/)
This is correct good catch.
>
> ....
>
> Tunnel Broker [TBRK, TSPB] is a useful tunneling mechanism, when the
> Enterprise wants to automate the setup of tunnels in the enterprise,
> and a tunnel broker can be used to support 6to4, ISATAP, and DSTM
> mechanisms. Tunnel Broker set-up protocol is being submitted as an
> IETF Experimental RFC.
>
> ==> I believe at least TSP has considered "Informational"
> instead (at least
> that's what Florent said). The base spec, AFAICS, does not
> include the
> 6to4, ISATAP, and DSTM extensions, so I'd suggest removing
> that part of the
> sentence.
Just need to check with TBRK authors.
We will review all the valid semi-editorial comments below they add
value to the spec so thanks for those below.
Thanks for your input,
/jim
> semi-editorial
> --------------
>
> -- maybe still not clear enough what the 'host X network' means?
>
>
> [In section 4.4.2.1]
> In the widespread dual-IP scenario, a more structured, manageable
> method is required, where the administrator has control of the
> deployment per-link and (ideally) long-term, aggregatable global
> IPv6 addressing is obtained, planned and used from the outset.
>
> ==> I don't understand the relevance of v6 addressing to the tunnel
> discussion. Maybe some of this text should be removed or elaborated?
> (If obtaining global addresses is/should be mentioned, it
> should probably be
> done higher in the document hierarchy?; this is mentioned in
> 7.3 at least)
>
> When the enterprise's users are off-site, and using an ISP that
> does not support any native IPv6 service or IPv6 transition aids,
> the enterprise may consider deploying it's own remote IPv6 access
> support, as described in Section 7.5.2 below.
>
> ==> there is no section 7.5.2 ..?
>
> 5.1 Internal versus External Tunnel End Point
>
> Let's assume the upstream provider has deployed some IPv6 services,
> either native IPv6 in its backbone or in the access network, or
> some combination of both (Scenario B of Table 1). [...]
>
> ==> this has some very good text, but is this (enterprise has
> no v6 infra)
> on the borderline of being out-of-scope, wrt. the paragraph in Intro:
>
> 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. [...]
>
> (these two cases are, at least from the ISP's perspectively,
> apparently
> pretty close to equivalent..) So, I'm not sure whether
> changes or further
> applicability text would be useful. I think the external tunnel point
> discussion may also apply to Scenario F and some others (e.g., if your
> business partner would want to use v6 application to reach
> your v6 app, but
> you'd have to provide a tunnel to him.
>
> .....
>
> For internal routing, an appropriate interior routing protocol may
> be deployed. IPv6 routing protocols that can be used are as
> follows: BGP4+ [BGP4], IS-IS [ISIS], OSPFv3 [OSPF] and RIPng
> [RIPng].
>
> ==> maybe a more informative way for the reader would be to
> point to the ISP
> analysis on the routing protocol selection (the only
> difference here is that
> RIPng may be a bit more applicable in enterprise networks,
> but I'm not sure
> whether that is worth mentioning), for example:
>
> For internal routing, an appropriate interior routing protocol may
> be deployed. The routing protocol selection and the tradeoffs
> have been discussed in Section X of [ISPA], also applicable here.
>
> ....
>
>
> ...
>
> Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6];
> there is support for DHCPv6 to assign privacy addresses to nodes in
> managed environments.
>
> ==> I'd say more briefly and less controversially:
>
> Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6];
> there is also support for DHCPv6 to assign privacy addresses.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> editorial
> ---------
>
> 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.
>
> ==> isn't this saying almost the same thing twice? maybe
> slight reword.
>
> - Requirements or Transtion at the Providers network
>
> ==> s/Trans/Transi/ (this seems a bit obvious as well,
> because this is an
> enterprise doc, not provider doc..)
>
> We are also assuming that the enterprise deployment is one being
> undertaken by the network administration team, i.e. this document
>
> ==> remove "one" ?
>
> enterprise. In sectioin 7 we discuss general issues and
>
> ==> s/sectioin/section/
>
> The notional enterprise network is comprised of hosts attached to
>
> ==> do you mean "notational" with notional or something else?
> (many instances of this)
>
> Obviously Table 1 does not describe every possible scenario.
> Trivial notional networks (such as pure IPv4, pure IPv6, and
> ubiquitous Dual-IP) are not addressed. However, the authors feel
> these ten represent the vast majority of transitional situations
> likely to be encountered in today's enterprise. Therefore, we will
> use these ten to address the analysis for enterprise deployment.
>
> ==> this seems to overlap with an earlier (and more fleshed
> out) paragraph
> starting with "Addressing every possible combination of network
> IP-capability in this notional enterprise network is
> impractical, [...]".
> I'd suggest some combining to remove the overlap.
>
> use IPv6 applications, but has yet to transition its internal
> networks and it's Service Provider also lags, offering only a v4
> IP-service.
>
> ==> s/it's/its/ (the same in a couple of other places)
>
> Consider the situation where there exists IPv6 edge routers which
> are IPv6-capable, while others,and perhaps the enterprise backbone
>
> ==> s/,and/, and/
>
> There is a need for end-to-end communication with IPv6, but the
> infrastructure only supports IPv4 routing. Thus, the only viable
> method for end-to-end communication with IPv6 is to tunnel the
> traffic over the existing IPv4 infrastructure, within this analysis
> documents boundaries defined.
>
> ==> I'm not sure if I understand the last part of the last sentence,
> starting from "within ...". Maybe slight reword?
>
> IPv6-dominant network, except if required at to support edge IPv4
> networks.
>
> ==> remove "at" ?
>
> In each case, communicating with an IPv4 end host or over an IPv4
> network requires a transition point exist within the network to
> support that operation.
>
> ==> s/a transition point exist/that a transition point exists/
> or s/exist/to exist/ ?
>
> network must aquire an IPv4 address (to interoperate with the IPv4
>
> ==> s/aquire/acquire/
>
> IPv6 Privacy Extensions, end-to-end IPSEC, and, not least, the use
>
> ==> s/IPSEC/IPsec/
>
> this mechanism provides no automated tunnnel configuration.
>
> ==> s/tunnnel/tunnel/
>
> driven by the position of the incompatible touchpoint. If a local
> network is incompatible than host tunneling is appropriate. If the
>
> ==> s/than/then/
>
> service both IPv4 and IPv6 data streams that are simulataneously
>
> ==> s/simulataneously/simultaneously/
>
> The following transition mechanism have at least two independent
>
> ==> s/mechanism/mechanisms/
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>