Subject: WGLC ent-analysis-03

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Aug 2005 22:51:03 +0300 (EEST)

Hi,

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.

Flights are good at catching up on your reading list :)

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

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

2) [see separate mail on app vs network-driven]

3) [see separate mail on DSTM]

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

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

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.

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

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

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

  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.

........

  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.

.......

  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.

....

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

....

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.

....

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.

....

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.

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

....

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.

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

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 8 Aug 2005 08:05:22 -0400

thanks for in depth review and comments.  Will respond to each point and
we highly appreciate your consistent review  of this spec and support we
are going to make it very clear in the final spec of your significant
contributions and logic check to us technically.  Sorry I am still
behind from all the IETF work.  Will catch up as I can.

THANK YOU BIG TIME.

/jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Pekka Savola
> Sent: Friday, August 05, 2005 3:51 PM
> To: [email-masked]
> Subject: WGLC ent-analysis-03
> 
> Hi,
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 17 Aug 2005 06:59:12 -0400

Hi Pekka,

Others are responding to DSTM below are comments on other points for the
work. 

> addition) still requires wider review.

Thanks.

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

> understand its basic assumptions.)

We mean incompatible networks in the matrix we can word smith this yes.

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

>   effort not a operative or protocol specification.

Personally I agree.  Will discuss with authors.

> instead/in addition because it's replacing BCNF)

Will discuss ok.

> SEC1 (not referred), OSPF, BGP4, ISIS, RIPng

Will discuss.

> almost substantial

Yes the above.

> strongly tied to the scenarios.

We can make this clearer I believe per your mail. 

>   configured tunnels may be preferable especially if the number is

Personally I like this wording and will suggest to authors.

>   may also choose to only distribute configuration information using

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.

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

> or C.  Manual Configured Tunnels for IPv6 is an IETF Proposed 

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.

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

> being reclassified to experimental.

Will do.

> (similar applies to the other mechanisms.) (also s/partic/partici/)

This is correct good catch. 

> 6to4, ISATAP, and DSTM extensions, so I'd suggest removing 

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