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

From: Pekka Savola <[email-masked]>
Date: Sat, 1 Mar 2003 16:32:03 +0200 (EET)

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:[email-masked]". 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

---

From: Ronald van der Pol <[email-masked]>
Date: Mon, 3 Mar 2003 15:05:36 +0100

> It's (on a higher level) fine by me, at least.

I think you are right that ideally the scenario drafts should not do
analyses. But I think making some choices to limit the analysis draft
is not too bad.

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

I guess we could do that.

> out of scope, or that's the impression I get based on the first paragraph.

We have been discussing multiple-subnet cases internally, especially an
802.11b router connected to a home LAN behind a SOHO router to the ISP.
In the IPv4 case this usually is a NAT behind a NAT :-(

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

True.

> why only "privacy" part of "security" was taken into consideration.

It said security first, but than some in the design team noted that it
was more about privacy than security :-)

> placed somewhere else in the document, maybe?

It already is. Section 4 is not specific to one scenario, but to all.

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

True.

> services, especially if one has a NAT to traverse -- I'm sure we all agree

I don't think it's about smoothness, but about stability. You want the
server to have a stable (over a long time) IPv6 address. And I think
services are important for unmanaged networks. Think about all kinds of
IPv6 appliances in a home that one can reach from anywhere.

> requests, not the DNS support itself.

OK, I guess you can read it in different ways. But is says "is difficult
to engineer" and I think that is the main point.

> not necessarily the case.

True, but in the scenario drafts we try to describe the most common cases.
And unfortunatly, it seems NATs are very common.

> any case -- I can only try to guess what it means)

OK.

> explicit in the text in some way.

OK.

Thanks for your comments.

	rvdp

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Mar 2003 13:19:34 +0200 (EET)

Commenting only to left-overs..

> In the IPv4 case this usually is a NAT behind a NAT :-(

The best in this case might be to deploy the 801.11b router to act as a 
bridge.

But in any case, the scenarios document should be clearer on what is 
considered "in scope" for the unmanaged networks.
 
> was more about privacy than security :-)

Yes, I agree it's better to have a title corresponding to the text, but 
even better would be having multiple titles or justification why other 
parts of security weren't elaborated at that length.
 
> It already is. Section 4 is not specific to one scenario, but to all.

Oh ok, missed that.

> IPv6 appliances in a home that one can reach from anywhere.

Yes, I very much like to see IPv6 appliances and connectivity in place.

What I was trying to get at with the comment was that the so-called 
"connection survivability" or "DNS with zero TTL" should not be a problem 
in the unmanaged networks.

It's nice to have a stable IPv6 address, but one can survive with a 
downtime of a few hours, even a day (e.g. a delay in updating the DNS, DNS 
record lifetimes) -- which might not be acceptable in e.g. enterprise 
networks.
 
> to engineer" and I think that is the main point.

To me "difficult to engineer" doesn't really tell much, because I want to 
see some answer to the "why is it difficult to engineer?" as the answer is 
not obvious (or different people have different opinions on why exactly 
it's difficult).
 
> And unfortunatly, it seems NATs are very common.

In some places, they are; in some others, they might not be.  Unless it's 
very painful, I'd try to cover both cases at least in some detail (so that 
folks who are *not* harmed by NAT's at that particular place don't throw 
the scenarios document out of the window as irrelevant).

---

From: Francis Dupont <[email-masked]>
Date: Sun, 09 Mar 2003 17:04:13 +0100

Here is my review of draft-ietf-v6ops-unman-scenarios-00.txt,
I have no concern but some comments and editorial remarks.

Comments

 I have no concern about the limitation to a single subnet as soon
 as it is clear from the beginning (and it is the case).

 A very common scenario (the one I use personally) is a VPN (with
 IPsec or SSH or both) which injects the home network into a virtual
 home site. I don't know if this should be explicitly considered but
 at least it should be put out of the scope of the document by
 a statement in the introduction.

 A DNS server can be recursive (i.e., be a "DNS proxy") or not. As
 almost all resolvers don't support recursion them selves, this is
 an important detail when the DNS crosses IP version domains.

Typos & co:

 2	Topology

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

 3	Applications

   types of applications: local, client, servers and peer-to-peers.

=> types of applications: local, client, server and peer-to-peer.

 3.1	Local applications

=> of the unmanaged network. Typical examples are the sharing of files

 3.2	Client applications

=> Client applications tend to work correctly in IPv4 unmanaged

 4.2	Requirements of client applications

   servers. In an IPv6 network, the client must be able to locate a DNS
   server.

=> perhaps this is the good place to introduce recursive DNS servers?
Note: in BIND the recursion part is in the server itself, i.e., even a
caching only server adds recursion support to the resolver but the
scenarios are about *unmanaged* networks, i.e., IMHO without any
BIND server by default.

=> I agree with the conclusion.

=> insert a page break between 4.3 and 4.4 sections.

 5.1.2	Addresses and connectivity in Case A

   to deploy, and light weight; it will have to involve tunneling over
   UDP, as this is the practical way to traverse a NAT. If servers are

=> s/UDP/& or TCP/
(SSH is a good example of TCP tunneling which works through NATs)

 5.2.1	Application support in Case B

   all, and to just continue fielding IPv6-only devices. The remaining

=> please replace "fielding" by a more common term.

   be assessed in a companion memo [EVAL].

=> as soon as there is a reference to [EVAL], there should be others.

   compared in the evaluation draft.

=> add [EVAL].

 5.4.1	Application support in Case D

   by providing IPv4-over-IPv6 tunnels. Our analysis concludes that a
   tunnel service will be vastly preferable.

 and

   The proper alternative to application relays and network address
   translation is the provision of an IPv4-over-IPv6 service.

=> I agree (:-)!!!

 5.4.3	Naming services in Case D

   The gateway should be able to act as a "DNS proxy" for the remaining
   IPv4 only hosts.

=> this "DNS proxy" is in fact a recursive DNS server running on a dual
stack node.

 11	References

=> should be split into two sections, etc.

=> please add the name of the last version of the draft.

=> there is a [6TO4] in 5.3.2.

 Table of Contents:

=> move to front.

Thanks

[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Thu, 13 Mar 2003 13:02:52 -0800

I have a comment on draft-ietf-v6ops-unman-scenarios-00.txt.

Scenario case A:

 A) Gateway does not provide IPv6

By reading just this document, it sounds perfectly ok.
However, after reading the companion document,
draft-huitema-v6ops-unmaneval-00.txt, section 2.1.3:

   The tunnel approach is more expensive to provide, because the tunnel
   server will have to carry a much larger amount of traffic. It is
   unclear that a tunnel service can be provided as an almost free
   "supporting infrastructure", except perhaps if the service was
   directly provided by the same ISP that already provides IPv4
   connectivity to the unmanaged network.

I came to the conclusion that this scenario A is actually
combining 2 sub-scenarios:
A1- Gateway does not provide IPv6,
        ISP is cooperating to offer some level of v6 service
A2- Gateway does not provide IPv6,
        ISP is not cooperating

IMHO, the scenario document should reflect this.

This leads me to a larger issue, why should we rush publishing those
scenario documents as info RFC? The above is a clear example that
the scenarios may need to be revisited at the light of the analysis.

    - Alain.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Mar 2003 18:25:01 +0100 (CET)

Sorry for the late comment.

Major comment:

Section 4 says at the end of the first paragraph "simple and easy".
I think we should replace this with "secure and robust" or
add all the motherhood and apple pie.

My point is that by only including two motherhood words and not others
an attempt to use this document to evaluate potential solutions might be
slanted towards "easy" instead of "good".
I suspect the WG needs to discuss this aspect of the spec.

Section 3 makes a, in my opinion artificial, distinction between "p2p"
and "server" and then goes on to conclude that server is out of scope
due to the difficulty with DNS updates. This distinction seems a bit
artificial since the p2p aspect (that the same nodes both initiate and
respond to traffic) doesn't preclude that DNS is used.
So I'd think the document should capture that DNS updates might have issues
when the network is unmanaged that is independent of the types of applications
in section 3.

Minor things:
Per the rfc-editor the abstract and introduction should not be identical.

Section 2:
I'm assuming (but the document isn't clear) that if somebody figures
out how to autoconfigure a set of routers ("zerouter") that a network
with multiple links would be in scope.
Or is the intent that such networks always be out of scope?
It would be good to make this clear.

Section 3.2:
Is outbound SIP calls an example of a client application?
The reason I think it makes sense to make this explicit is because
the current examples are those that trivially work across a NAT box
and if this is the definition of "client application" it would make
sense to make it clear, and if the definiting is something different
(an entity that initiates communication) it would make sense
to make that clear.

Section 4.1 says:
   The security of local applications is enhanced if these applications
   can be effectively isolated from the global Internet.
Seems orthogonal to this document and a distraction.

Section 5.1.2 says "have to involve tunneling over UDP"
but in general using PPP over TCP works over NAT as well.
If you are trying to capture some specific requirement that excludes
PPP/TCP that needs to be explicit (and I suspect some folks will disagree
with such a requirement).

Section 5.2.3 talks about
   There must be a way to resolve the name of local hosts to their IPv4
   or IPv6 addresses.
Why isn't this a requirement in section 5.1.3 as well?

Section 6 says:

I fail to see what this has to do with the coexistence between IPv4 and IPv6.
*If* there is such a requirement wouldn't that requirement exist today
in IPv4 and wouldn't it exist in IPv6 even after IPv4 goes away?
If this is the case I don't think the requirement belongs in this document
but in a document for "requirements on home networks" or something like
that.

  Erik

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 19 Mar 2003 20:07:59 -0500

draft-ietf-v6ops-unman-scenarios-00.txt says:

5.3	Case C, IPv6 connectivity without provider support

...

5.3.2	Addresses and connectivity in Case C
   
   The upgraded gateway will behave as an IPv6 router; 

<MB> not the only way to do it. one host inside the internal network could
be the v6 router. Text should be fixed.</MB>

it will continue
   providing the IPv4 connectivity of non-upgraded NAT. Nodes in the
   local network will obtain:
   
   	- IPv4 natted addresses,
   	- IPv6 link local addresses,
   	- IPv6 global addresses.
   
   The clients could also obtain IPv6 site local addresses, if the
   gateway advertises a site local prefix; this raises the same issues
   already discussed in case B.
   
   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. 
<MB>not the only ways.</MB>

Both technologies have advantages
   and limitations, which will be studied in a companion document.
   
<MB>additional comment: I've not found text that clearly states that prefix
delegation is required.</MB>

Marc.