Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt

[Pekka Savola <pekkas@netcore.fi>]

Hi,

On Mon, 17 Feb 2003, Margaret Wasserman wrote:
> This is a WG Last Call for comments on sending the Unmanaged
> Networks scenarios document to the IESG for consideration as
> an Informational RFC:
> 
> Title:     Unmanaged Networks IPv6 Transition Scenarios
> Filename:  draft-ietf-v6ops-unman-scenarios-00.txt
> Authors:   C. Huitema, R. Austein, R. van der Pol
> Date:      January 10, 2003
> 
> The document can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-scenarios-00.txt

I've re-read the document.  It seems good and I agree with the overall 
approach, but IMO a bit raw yet.  As a scenario document, it seems to go a 
bit further than some might expect (see below) -- is this OK?

The biggest (potential) issue:

==> the document goes beyond describing the current IPv4 deployments in
several places, like 5.2.1 and 5.4.1; personally, these have typically
been "rough solution scoping" -type approaches, and suggestions seem
pretty good to me, at least.  

However, they may or may not be appropriate as is.

Is this a sensible approach?  Does someone see a process issue here?  
It's (on a higher level) fine by me, at least.

(one approach might be tone down the language in these a bit e.g. in:

 Our analysis concludes that a tunnel service will be vastly preferable.

change to:

 Our analysis concludes that tunnel service seems to be vastly preferable.

===========

Substantial/semi-editorial issues:

2 Topology
 
==> this section somewhat defines the context of the unmanaged network:  
should there be an explicit definition of it for the purposes of this doc,
and the solutions document (might not be easy)?

A particular thing I note that multiple-subnet case seems to be 
out of scope, or that's the impression I get based on the first paragraph.


   Deploying servers usually requires providing the servers with a
   stable DNS name, and associating the global IPv4 address of the
   nat/firewall with that name.

==> associating with the address of _NAT/firewall_?  If there is NAT, 
that's something that has to be done, yes.  

==> So, if there is no NAT, this needs rewording.

==> s/requires/also requires/ (noticed the intent on second 
read, perhaps this is enough), else: this overlooks the required 
step that you must also somehow configure a mapping in the 
NAT/firewall box.

4.1     Requirements of local applications

[...]

   The security of local applications is enhanced if these applications
   can be effectively isolated from the global Internet.

==> should this "enhancement" be strengthened to a (loose) requirement, or 
something?  Sounds awfully weak to me..  If not, might have a problem with 
security considerations text.

4.2.1   Privacy requirement of client applications

==> this sub-section should be preceeded by a short paragraph describing 
why only "privacy" part of "security" was taken into consideration.

==> bigger issue: isn't this text applicable to all cases A-D?  Could be 
placed somewhere else in the document, maybe?

   Randomization of the host identifier does however provide benefits.
   First, if some of the hosts in the unmanaged network are mobile, the
   randomization destroys any correlation between the addresses used at
   various locations: the addresses alone could not be used to
   determine whether a given connection originates from the same laptop
   moving from work to home, or used on the road.

==> this seems rather an issue for mobile computers, not specific for 
unmanaged networks.

Second, the
   randomization removes any information that could be extracted from a
   hardwired host identifier; for example, it will prevent outsiders to
   correlate a serial number with a specific brand of expensive
   electronic equipment, and to use this information for planning
   marketing campaigns or possibly burglary attempts.

==> if this is the fear, there may be simpler fixes for the problem, e.g.  
resetting the MAC-address statically to one picked as locally unique.  I
think there is even a reserved "private use" range, but can't find it at
the moment.

4.4     Requirements of server applications
[...]
   The DNS entries for the server will have to be updated, preferably
   in real time, if the server's address changes. In practice, updating
   the DNS is slow, which implies that server applications will have a
   better chance of being deployed if the IPv6 addresses remain stable
   for a long period.
[...]

==> please consider the context here.  Personally, as one who has services
on his home PC (acting also as a router), like SSH access, I don't feel
absolute smoothness is a requirement.  A nice thing to have, surely, but
not a requirement.  Unmanaged network is *NOT* the place to run critical
services, especially if one has a NAT to traverse -- I'm sure we all agree
on that.

Perhaps this should be clarified slightly somehow.

   Server applications are also not a primary focus of Case A. Server  
   applications require DNS support, which is difficult to engineer for
   clients located behind a NAT.

==> "DNS support" should IMO be clarified or elaborated.  This is 
actually not the case, AFAICS.  Of course, publishing a DNS update is a 
problem, but the root cause seems to be configuring the NAT to forward the 
requests, not the DNS support itself.

We also
   observe that providing both IPv4 and IPv6 connectivity in an
   unmanaged network is not particularly difficult; indeed there is a
   well established experience of using IPv4 in these networks in
   parallel with other protocols such as for example IPX.

==> this seems a bit like comparing apples and oranges: I'm not aware that
external IPX connectivity has been provided by the ISP: anything at all
can be used locally, but that's not the point.  Perhaps the example
scenario needs to be worked out a bit?

5.2.2   Addresses and connectivity in Case B

   In Case B, the upgraded gateway will behave as an IPv6 router; it
   will continue providing the IPv4 connectivity of a non-upgraded NAT.
   Nodes in the local network will obtain:

(same in 5.3.2)

==> the document assumes that in case B, the NAT is being used.  That's 
not necessarily the case.

==> (editorial: "connectivity of a non-upgraded NAT" needs rewording in 
any case -- I can only try to guess what it means)

5.2.3   Naming services in Case B

   At this phase of IPv6 deployment, hosts in the unmanaged domain have
   access to DNS services through the gateway.  As the gateway and the
   ISP both support IPv4 and IPv6, these services may be accessible by
   the IPv4 only hosts using IPv4, by the IPv6-only hosts using IPv6,
   and by the dual stack hosts using either. 

==> the first sentence is (almost) always true -- note that IPv6-only host
in Case B cannot use DNS services unless they're provided on IPv6
transport.  However, you should really elaborate which "DNS services" you
refer to.  Perhaps in the first line, s/hosts/IPv6-only hosts ... domain 
also have .../ or the like.

   The response to a DNS request should not depend of the protocol with
   which the request is transported: dual-stack hosts may indifferently
   use IPv4 or IPv6 to contact the local resolver; the choice of IPv4
   or IPv6 will be random; the value of the response should not depend
   of a random event.

==> s/will/may/ -- depends on several factors?

   There are two ways to bring immediate IPv6 connectivity on top of an
   IPv4 only infrastructure: automatic tunnels provided by the [6TO4]
   technology, or configured tunnels. Both technologies have advantages
   and limitations, which will be studied in a companion document.

==> much as I like e.g. 6to4, this should really be reworded slightly, not 
to advocate any solution.  The simplest acceptable fix would be changing 
it to:

   There are two ways to bring immediate IPv6 connectivity on top of an
   IPv4 only infrastructure: automatic tunnels, e.g. provided by the [6TO4]
   technology, or configured tunnels. Both approaches have advantages
   and limitations, which will be studied in a companion document.

.. or even strike the 6to4 part off completely.

Any interaction between
   hosts in the unmanaged network and IPv4 hosts on the Internet will
   require the provision of some inter-protocol services by the ISP.

==> (and later, even more so) -- one should perhaps add an informative 
reference to the ISP scenarios document.  In a way, unmanaged team gives a 
suggestion for the long-term ISP transition plan, and that should be more 
explicit in the text in some way.

   The loss of IPv4 connectivity has a direct impact on the provision
   of naming services. An obvious consequence is the gateway will have
   to be provisioned with the address of a DNS server and with other
   DNS parameters, and that this provisioning will have to use IPv6
   mechanisms.

==> I fail to see why the gateway would *necessarily* have to be 
configured.  Of course, in most cases, it makes a sense to run a caching 
resolver/forwarder there, but it's not necessary AFAICS.  Loss of IPv4 
connectivity means that (restricting to the scenario advocated in the 
document) that the gateway or a host opens an IPv4-in-IPv6 tunnel to the 
ISP.  From there, the DNS services (over v4) could be used directly.

6       Security Considerations

   Security considerations are discussed as part of the applications'
   requirements. They include:

   -    the guarantee that local applications are only used locally,
   -    the protection of the privacy of clients
   -    the requirement that peer-to-peer connections are only used by
   authorized peers.
 
==> I fear this is a bit on the weakish side for security considerations 
:-(

==> one particular point that wasn't discussed (much) on the draft or here 
is the connection between applications and possible firewall rules in IPv6 
network at the gateway (consider e.g. p2p apps).  But this is a difficult 
problem..

==> in particular, one approach in a document like this could be to try to 
list some security features currently being used in IPv4 unmanaged 
networks, and try to identify the issues which will need to be tackled now 
(later).  Solutions aren't necessary in this document, but recognizing the 
changes in assumptions etc. would be very good.  This is *especially* 
important in unmanaged networks, I'm afraid -- as they seem to constitute 
about the greatest risk for abuse.


11      References

   [EVAL] Evaluation of Transition Mechanisms for Unmanaged Networks,
   work in progress.

==> References need to be split ;-) (and given in the proper format), but
really: more references should be added, even if informative!

==================


.. and then for more or less editorial issues ..


==> should you add an informational reference to the latest traditional 
NAT RFC?
(I was triggered to this by section 3.4, before it was simple enough..)

==> section titles must be mainly in uppercase (e.g. Local 
applications --> Local Applications).

==> The text uses active forms like "We saw [...]" etc.  Typically, the 
passive mode is used, but I guess this is also ok.

==> dual stack vs dual-stack (use one for consistancy), similar with IPv4 
only vs IPv4-only and IPv6.

==> s/site local/site-local/g, s/link local/link-local/ (everywhere)

Table of Contents:

==> ToC must be up in the beginning, after the abstract, according to the 
policy.

Abstract

   In order to evaluate the suitability of transition mechanisms, we
   need to define the scenarios in which these mechanisms have to be
   used. One specific scope is the "unmanaged networks", which
   typically correspond to home networks or small office networks.

1       Introduction

   In order to evaluate the suitability of transition mechanisms, we
   need to define the environment or scope in which these mechanisms
   have to be used. One specific scope is the "unmanaged networks",
   which typically correspond to home networks or small office
   networks.

==> Abstract is too terse; it should also include some text 
on the contents of the memo, not just the background.

==> Abstract/Introduction is out of sync

==> Introduction should (IMO) give some very brief overview
of the layout of the draft ("why sections like this?") -- 
so that the red line does not disappear when reading it.

   (ISP)connection. Several hosts are connected to the subnet:

==> s/connection/ connection/
==> s/are/may be/

   static policies. There are however many cases in which the gateway

==> s/however/, however,/

   of the unmanaged network. Typical examples are the sharing of file

==> s/file/files/

3.2     Client applications
[...]
   Local applications tend to work correctly in IPv4 unmanaged

==> s/Local/Client/

   to-peer" that only involve hosts on the unmanaged network, and the
   "remote peer-to-peer" that involve both hosts on the unmanaged
   network and hosts outside the network.

==> s/hosts/host(s)/ -- not sure if this is strictly necessary, 
though, and whether it improves readibility..

 We will only consider here
   the "remote peer-to-peer" applications

==> s/We will only consider here/Here, we will only consider/

   applications are a subset of the "local applications."

==> s/."/"./ ?

   well identified peers outside the unmanaged network. These

==> s/well identified/well-identified/ ?

  networks. Examples of a peer-to-peer application would be a video-

==> s/a peer-to-peer application/peer-to-peer applications/

   conference over IP, facilitated by a SIP server, or a distributed

==> the SIP abbreviation should probably spelled out here, 
as used for the first time.

3.4     Server applications

   Server applications involve running a server in the unmanaged
   network, for use by other parties outside the network. Examples
   would be running a web server or an e-mail server on one of the
   hosts inside the unmanaged network.

==> s/hosts/nodes/ ?  
(you should be able to run them also on the gateway box, right..?)

  nat/firewall with that name. Since updating DNS is a management

==> s/nat/NAT/

4       Application requirements of an IPv6 unmanaged network

==> the intent should be clearer: "Requirements of Applications for IPv6 
Unmanaged Networks" vs. "IPv6 Unmanaged Network Requirements for 
Applications"?  I assume the former..

   include the provision of IPv6 addresses and their quality: do host

==> s/do/does/ or /host/hosts/ ?

   Local applications require local connectivity. They must continue
   working even if the unmanaged network is isolated from the Internet.

==> s/continue working/continue to work/ (sounds much better that way, at 
least..)? -- the same later in a place or two.

   We may debate whether the IPv6 networking service should be

==> s/We may debate/It is debatable,/ ?

   manages a static IPv4 address; in both case, the IPv4 address or the

==> s/case/cases/

   Randomization of the host identifier does however provide benefits.

==> s/however/, however,/ ?

   hardwired host identifier; for example, it will prevent outsiders to
   correlate a serial number with a specific brand of expensive

==> s/prevent ... to correlate/prevent ... from correlating/ ?

   all unmanaged network allow use of privacy addresses by those hosts
   who so choose.

==> s/who so choose/which choose to do so/

   which will have to remain stable for the duration of the peer-to-
   peer between client and server.

==> s/peer-to-peer/peer-to-peer session/

   "sip:user@example.com". A peer to peer session typically starts by

==> s/peer to peer/peer-to-peer/ -- for consistancy?

   (possibly including ISP CPE), the home gateway and the hosts

==> need to spell out CPE when used for the first time?

   an IPv6 based service; economic reality implies that the cost of

==> s/IPv6 based/IPv6-based/ ?

   Reverse lookup is hard to provide if the gateway is not upgraded.   

==> s/hard/difficult/

   well established experience of using IPv4 in these networks in

==> s/well established/well-established/ ?

   from network connectivity events and network based attacks; however,

  gateway advertises a site local prefix. This is as debatable: site

==> s/as debatable/debatable/ ?

==> s/network based/network-based/

   managing non unique addresses can be problematic if some local hosts

==> s/non unique/non-unique/

   To enable this scenario, the gateway need to use a mechanism obtain

==> s/need/needs/, s/obtain/to obtain/

   discover the IPv4 address of the local DNS server using DHCP; there 

==> s/DNS server/DNS resolver/g (a few times, also under case D) ?

   variations of domain name delegation. If we want to provide
   efficient reverse lookup functions, delegation of a fraction of the
   ip6.arpa tree is also required.

==> use e.g. "If efficient rev.. functions are to be provided, ..."

   In this case the gateway is IPv6 capable, dual stack, the ISP is
   not. The gateway has been upgraded and offers both IPv4 and IPv6
   connectivity the hosts.

==> s/IPv6 capable/IPv6-capable/
==> s/the ISP/but the ISP/
==> s/offers/would be able to offer/ ?

The network level 
   protocol translation service appears to not be very desirable.  

==> s/.../doesn't appear to be very desirable/ ?

Once such
   addresses have been provided, the gateway effectively acquires dual-
   stack connectivity; for hosts inside the unmanaged network, this
   will be indistinguishable from the connectivity obtained in case B
   or C.

==> need to clarify "connectivity" in the text, because case B/C don't
really deal with other than _IPv6_ connectivity: e.g. "IPv4 connectivity",
right?

   of naming services. An obvious consequence is the gateway will have

==> s/is/is that/ -- for clarity

   through an IPv6 address documented in a AAAA record. However, the

==> s/a AAAA/an AAAA/ (could be used both ways if you pronounce quad-A, I 
guess)



some misc editorial comments I misplaced:

   In this case the ISP is IPv6-only, so the gateway looses IPv4
   connectivity

==> s/loose/lose/ (or change the word ...)

   At this phase of the transition, IPv6 hosts can perform all types of
   applications with other IPv6 hosts. IPv4 hosts in the unmanaged
   network will be able to perform local applications with IPv4 or dual
   stack local hosts.

==> replace the word "perform" with something else (I can only try to 
guess what it means..)

   There are three possible ways that an ISP can provide hosts in the
   unmanaged network with access to IPv4 application: by using a set of

==> s/application/applications/ ?

We also observe that
   in an IPv6-only ISP the application relays would only be accessible
   over IPv6,

==> s/ISP/ISP,/ (helps readability even though not required)


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