Subject: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt

From: Pekka Savola <[email-masked]>
Date: Tue, 10 Feb 2004 08:25:16 +0200 (EET)

Hi all,

This is a WG Last Call for comments on sending
draft-ietf-v6ops-unmaneval-01.txt, "Evaluation of Transition
Mechanisms for Unmanaged Networks" to the IESG for consideration as
BCP:

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unmaneval-01.txt

Please review these documents carefully, and send your feedback to the
list.  Please also indicate whether or not you believe that this document
is ready to go to the IESG.

The last call will end in about 2 weeks, on 26th February.

Pekka & Jonne

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 27 Feb 2004 00:32:43 -0500

good work and document. extracted text with comments tagged with <MB></MB>
and suggestion of text.

Marc.

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

   A) a gateway which does not provide IPv6 at all;
   B) a dual-stack gateway connected to a dual-stack ISP;
   C) a dual-stack gateway connected to an IPv4-only ISP; and
   D) a gateway connected to an IPv6-only ISP.

<MB>in both the scenario and the eval, the term "dual-stack" ISP
is used. just wondering if an ISP network can really be named
"dual-stack". Would "dual protocol network" be more appropriate name?</MB>

   During the transition phase from IPv4 to IPv6 there will be IPv4-
   only, dual-stack or IPv6-only nodes. In this document, we make the

s/or/and/

2.1	Comparing automatic and configured solutions

   It is possible to broadly classify tunneling solutions as either
   "automatic" or "configured".

<MB>"configured' is used in other ietf documents to denote manually
configured static tunnels. However, in this document, configured 
usually means the tunnel broker configured tunnels, either with 
the web or the TSP model; since
the manually configured static tunnels is obviously not an unmanaged
solution. However, sometimes the comments on configured tunnels are related
to the manually configured static tunnels. 
To avoid confusion, it was 
suggested during a presentation in Vienna, the word
"negociated tunnels" to denote the kind of configured tunnels set by
tunnel brokers and the like. Would suggest "negociated tunnels" to be
used in the document, so the reader will understand the difference with
the manually configured static tunnels. 

Suggesting to s/configured tunnels/negociated tunnels/g  throughout the text
</MB>

 In an automatic solution, a host or a
   router builds an IPv6 address or an IPv6 prefix by combining a pre-
   defined prefix with some local attribute, such as local IPv4 address
   [6TO4] or the combination of an address and a port number [Teredo].
   Another typical and very important characteristic of an automatic
   solution is they aim to work with a minimal amount of support or
   infrastructure for IPv6 in the local or remote ISPs. In a configured
   solution, a host or a router identifies itself to a tunneling
   service to set up a "configured tunnel" with an explicitly defined
   "tunnel router".

<MB>negociated tunnels have the same aim to work ... than automatic tunnel.
Suggesting text to replace "Another typical ... "tunnel router":

   For negociated tunnels, a host or a router receives an IPv6 address
   or an IPv6 prefix from its tunnel broker, such as [TUNNELS] and [TSP].
   Another typical and very important characteristic of an automatic
   or negociated solution is they aim to work with a minimal amount 
   of support or infrastructure for IPv6 in the local or remote ISPs.
</MB>
   
   workarounds are probably possible). However, automatic tunnels have
   other advantages. They are obviously easier to configure, since
   there is no need of an explicit relation with a tunnel service.

<MB>6to4, teredo and [TSP] all require a single IPv4 address to be
configured. Moreover, one of the "automatic" tunneling technique
requires the configuration and knowledge of 2 IPv4 addresses.
So this comment is not appropriate.

Suggesting text:

"However, automatic tunnels and negociated tunnels are easier to
configure."

   In automatic tunnels like [Teredo] and [6to4], the bulk of the
   traffic between two nodes using the same technology is exchanged on

<MB> Is "direct path always possible in all cases between Teredo nodes?
</MB>

   a direct path between the endpoints, using the IPv4 services to
   which the endpoints already subscribe. By contrast, the configured
   tunnel servers carry all the traffic exchanged by the tunnel client.
   
   Path optimization is not a big issue if the tunnel server is close
   to the client, on the natural path between the client and its peers.
   However, if the tunnel server is operated by a third party, this
   third party will have to bear the cost of provisioning the bandwidth
   used by the client. The associated costs can be significant.

<MB>what is this cost compared/different to running a relay for 6to4 or
Teredo? Not clear to me what is the argument here. 
Suggesting: s/The associated costs can be significant// 
</MB>
   
...
   
2.1.2	Automatic tunnels and relays
   
   The economics arguments related to path optimization favor either
   configured tunnels provided by the local ISP or automatic tunneling
   regardless of the co-operation of ISPs. However, automatic solutions
   require that relays be configured throughout the Internet. If a host
   that obtained connectivity through an automatic tunnel service wants
   to communicate with a "native" host, 

<MB> s/"native" host/"native host or another host using another automatic
tunnel service"/
</MB>

it will need to use a relay
   service, and someone will have to provide and pay for that service.
   We cannot escape economic considerations for the deployment of these
   relays.
   
...
   
2.1.3	The risk of several parallel IPv6 Internets
   
   In an early deployment of the Teredo service by Microsoft,

<MB> s/Microsoft/one vendor/</MB>

...
   communications between 6to4 hosts. This will create an incentive for
   native hosts to somehow "multi-home" to 6to4, de facto creating two
   parallel Internets, 6to4 and native. This risk will only be
   mitigated if there is a sufficient deployment of 6to4 relays.

<MB>Suggesting to add the following text:
Negociated tunnels, such as [TUNNELS] or [TSP] do not have this risk
of several parallel IPv6 Internets.
</MB>
   
2.1.4	Lifespan of transition technologies
   
   A related issue is the lifespan of the transition solutions. Since
   automatic tunneling technologies enable an automatic deployment,
   there is a risk that some hosts never migrate out of the transition.
   The risk is arguably less for explicit tunnels: the ISPS who provide
   the tunnels have an incentive to replace them with a native solution
   as soon as possible.
   
   Many implementations of automatic transition technologies
   incorporate an "implicit sunset" mechanism: the hosts will not
   configure a transition technology address if they have native
   connectivity; the address selection mechanisms will prefer native
   addresses when available. The transition technologies will stop
   being used eventually, when native connectivity has been deployed
   everywhere. However, the "implicit sunset" mechanism does not
   provide any hard guarantee that transition will be complete at a
   certain date.
   
   Yet, the support of transition technologies has a cost for the
   entire network: native IPv6 ISPS have to support relays in order to
   provide good performance and avoid the "parallel Internet" syndrome.
   These costs may be acceptable during an initial deployment phase,
   but they can certainly not be supported for an indefinite period.
   The "implicit sunset" mechanisms may not be sufficient to guarantee
   a finite lifespan of the transition.
   
2.2	Cost and benefits of NAT traversal
   
   During the transition, some hosts will be located behind IPv4 NATs.
   In order to participate in the transition, these hosts will have to
   use a tunneling mechanism designed to traverse NAT.
   
   We may ask whether NAT traversal should be a generic property of any
   transition technology, or whether it makes sense to develop two
   types of technologies, some "NAT capable" and some not.  An
   important question is also which kinds of NAT boxes one should be
   able to traverse.  One should probably also consider whether it is
   necessary to build an IPv6 specific NAT traversal mechanism, or
   whether it is possible to combine an existing IPv4 NAT traversal
   mechanism with some form of IPv6 in IPv4 tunneling. There are many
   IPv4 NAT traversal mechanisms; thus one may ask whether these need
   re-invention, especially when they are already complex.
   
   A related question is whether the NAT traversal technology should
   use automatic tunnels or configured tunnels. We saw in the previous
   section that one can argue both sides of this issue. In fact, there
   are already deployed automatic and configured solutions, so the
   reality is that we will probably see both.

Huitema et al.                                               [Page  5]

INTERNET DRAFT  Unmanaged Networks Transition Tools  February 4, 2004

2.2.1	Cost of NAT traversal
   
   NAT traversal technologies generally involve encapsulating IPv6
   packets inside a transport protocol that is known to traverse NAT,
   such as UDP or TCP. These transport technologies require
   significantly more overhead than the simple tunneling over IPv4 used
   in 6to4 or in IPv6 in IPv4 tunnels. For example, solutions based on
   UDP require the frequent transmission of "keep alive" packets to
   maintain a "mapping" in the NAT; solutions based on TCP may not
   require such mechanism, but they incur the risk of "head of queue
   blocking", which may translate in poor performances. Given the
   difference in performance, it makes sense to consider two types of
   transition technologies, some capable of traversing NAT and some
   aiming at the best performance.
   
2.2.2	Types of NAT
   
   There are many kinds of NAT on the market. Different models
   implement different strategies for address and port allocations, and
   also different types of timers. It is desirable to find solutions
   that cover "almost all" models of NAT.

<MB>It appears to me that the goal is to cover _all_ models/behaviors
of NAT, not "almost all". Because the end user does not know behind
which kind of NAT he is, and we don't want him to know. However, the
end-user wants to have connectivity in all cases. I can't imagine
my laptop not getting IPv6 connectivity with a non-complete NAT traversal 
solution, where, in one specific hotel room, they are using a NAT which
does not work with the NAT traversal solution in my laptop. 

Suggesting: s/cover "almost all"/cover all/.
</MB>
   
...
   by many applications, e.g., networked games or voice over IP. The
   experience shows that most recent "home routers" are designed to
   support these applications. In some edge cases, the automatic
   solutions will require explicit configuration of a port in the home
   router, using the so-called "DMZ" functions.

<MB>only works for one single node. Moreover, it should be noted that this
explicit configuration is completly out of the _unmanaged_ goal.

Suggesting text:
using the so-called "DMZ" functions". These cases are obviously out of
scope of the unmanaged network scenario and only work for a single node
behind the NAT.
</MB>
   
2.3	Development of transition mechanisms
   
   The previous sections make the case for the development of four
   transition mechanism, covering the following 4 configuration:
   
   -	Configured tunnel over IPv4 in the absence of NAT;
   -	Automatic tunnel over IPv4 in the absence of NAT;
   -	Configured tunnel across a NAT;
   -	Automatic tunnel across a NAT.
   
   Teredo is an example of already designed solution for automatic
   tunnel across a NAT; 6to4 is an example of solution for automatic
   tunnel over IPv4 in the absence of NAT. 

<MB>all solutions should be mentionned. Suggesting to add this text:

s/absence of NAT./absence of NAT. [TSP] is an example of solution of
negociated tunnel over IPv4 in the absence of NAT and negociated tunnel
across a NAT.
</MB>

3.1	Evaluation of connectivity mechanisms
   
   In case A, IPv6 capable hosts seek IPv6 connectivity in order to
   communicate with applications in the global IPv6 Internet. The
   connectivity requirement can be met using either configured tunnels
   or automatic tunnels.
    
   An automatic solution like Teredo appears to be a good fit for
   providing IPv6 connectivity to hosts behind NAT, in case A of IPv6
   deployment. The service is designed for minimizing the cost of
   deploying the server, which matches the requirement of minimizing
   the cost of the "supporting infrastructure".

<MB>I don't understand why TSP was not suggested here at the same
level of Teredo as "good fit". Suggesting text:

s/An automatic solution like Teredo appears/Teredo and TSP appear/

3.2	Security considerations in case A
   
   A characteristic of case A is that an isolated host acquires global
  
<MB>text should be provided about the need of the relay function for
teredo and 6to4 and the security considerations of those relays. 
</MB>

...
   
4.3.1	Provisioning the address of a DNS resolver
   
   In an unmanaged environment, IPv4 hosts usually obtain the address
   of the local DNS resolver through DHCPv4; the DHCPv4 service is
   generally provided by the gateway. The gateway will also use DHCPv4
   to obtain the address of a suitable resolver from the local Internet
   service provider.
   
   The DHCPv4 solution will suffice in practice for the gateway and
   also for the dual-stack hosts. There is evidence that even the
   simple DNS resolvers present in small gateways can relay arbitrary
   DNS requests and serve arbitrary DNS records, including AAAA
   records.

<MB>I'm not sure I really understand or agree on the above paragraph.
I understand the comment as if the small gateway IP address is put
in the resolv.conf file of the node and that small gateway will
relay requests and response. My experience with small gateways and 
cable/dsl operators is that the small gateway is not involved as
relay for dns requests/answers. DNS request go directly from node to
DNS server of the ISP.
</MB>

4.3.2	Publishing IPv6 addresses to the Internet
   
...
   
   Dynamic configuration using the same type of ad hoc protocols that
   are common today is indeed possible, but the IETF should encourage
   the use of standard solutions based on Dynamic DNS (DDNS).

<MB>TSP does the configuration of Ipv6 address of the tunnel endpoint
(as well as the dns reverse tree in case of prefix delegation).
Suggesting text:

Tunnel Brokers[TSP or TUNNELS] do provide the publication of the IPv6
addresses as part of the establishment of the tunnel.

</MB>

5.1	Connectivity
   
   Connectivity in case C requires some form of tunneling of IPv6 over
   IPv4. The various tunneling solutions are discussed in section 2.
   The requirements of case C can be solved by an automatic tunneling
   mechanism such as 6to4 [6TO4]. An alternative may be the use of a
   configured tunnels mechanism [TUNNELS], but as the local ISP does is
   not IPv6-enabled this may not be feasible. 

<MB>do not agree with this conclusion: the local ISP might not have
upgraded its access infrastructure, but might have backbone or a 
cloud which is IPv6. Moreover, the upstream ISP might be IPv6.
Suggesting to:
 replace "such as 6to4 [6TO4]. An alternative ... feasible." 
 by:
 such as 6to4 [6TO4] or tunnel broker [TSP,TUNNELS]. 
 (and remove the "alternative way" sentence.

The practical conclusion
   of our analysis is that "upgraded gateways" will probably support
   the 6to4 technology, and will have an optional configuration option
   for "configured tunnels".

<MB>seems to imply many things about how vendors package their product.
not sure that is the "business" of IETF. Would suggest to change the 
wording to:
s/will probably support the 6to4 technology and will have ...tunnels"./
 might support 6to4 or TSP/
</MB>
   
   The tunnel broker technology should be augmented, to include support
   for some form of automatic configuration.

<MB> do not agree. TSP tunnel broker in anonymous auth mode is as
automatic as teredo or 6to4. 
Suggesting to remove the sentence "The tunnel broker ... configuration".

</MB> 

   Due to concerns with potential overload of public 6to4 relays, the
   6to4 implementations should include a configuration option that let
   user take advantage of specific relays.
   
6	Meeting the case D requirements
   
   In case D, the ISP only provides IPv6 services.
   
6.1	IPv6 addressing requirements

6.2	IPv4  connectivity requirements
   
   Local IPv4 capable hosts may want to still access IPv4-only
   services. The proper way to do this for dual-stack nodes in the
   unmanaged network is to develop a form of "IPv4 over IPv6"
   tunneling. This tunneling protocol need to be standardized. Part of
   the standardization will have to cover configuration issues, i.e.,
   how to provision the IPv4 capable hosts with the address of the
   local IPv4 tunnel servers.

<MB>do not agree, seems to imply there are no solutions in place. 
There are DSTM and TSP. TSP works today with this.
Suggesting to replace: "This tunneling ... tunnel servers."
 by:
TSP tunnel broker and DSTM are available for this purpose. TSP provides
a ubiquitous way to provide v6 in v4 with or without NAT and v4 in v6. 

</MB>

   After a careful analysis of the possible solutions, we can list a
   set of recommendations for the V6OPS working group:
   
   1- To meet case A and case C requirements, we need to develop, or
   continue to develop, four types of tunneling technologies: automatic
   tunnels without NAT traversal such as [6TO4], automatic tunnels with
   NAT traversal such as [TEREDO], configured tunnels without NAT
   traversal such as [TUNNELS] and configured tunnels with NAT
   traversal.

<MB>s/configured tunnels without NAT traversal such as [TUNNELS]/
configured tunnels without NAT traversal such as [TUNNELS,TSP],
configured tunnels with NAT traversal[TSP] and IPv4 in IPv6 tunnels
with [TSP]./
</MB>
 
   2- To meet case B "informal prefix sharing" requirements, we would
   need a standardized way to perform "ND proxy", possibly as part of a
   "multi-link subnet" specification. (The explicit prefix delegation
   can be accomplished through [PREFIXDHCPV6].)
   
   3- To meet case B naming requirements we need to proceed with the
   standardization of LLMNR. (The provisioning of DNS parameters can be
   accomplished through [DNSDHCPV6].)
   
   4- To meet case D IPv4 connectivity requirement, we need to
   standardize an IPv4 over IPv6 tunneling mechanism, as well as the
   associated configuration services.

<MB> again, do not agree. already in place. 
Suggesting to delete 4- since text is added in 1- for that purpose.
</MB>

8	Security considerations
   
   This memo describes the general requirements for transition
   mechanisms. Specific security issues should be studied and addressed
   during the development of the specific mechanisms.
   
<MB>a discussion and reference to draft on security of relays should
be provided here</MB>

13	References
   
   Normative references

<MB>to add:

[TSP] Blanchet, M. "IPv6 tunnel broker with Tunnel Setup Protocol (TSP)",
Work in progress, draft-blanchet-v6ops-tunnelbroker-tsp-00.

</MB>

<MB>would suggest to add draft filenames in references to make easier
to find the documents</MB>

---

From: Pekka Savola <[email-masked]>
Date: Mon, 1 Mar 2004 00:15:17 +0200 (EET)

Thanks for your feedback.

I'm responding on some non-trivial issues inline .. some of this will 
no doubt be discussed at the IETF as well..  In short, I think I agree 
to some degree in most places where you raise issues -- that some 
text changes are needed -- but don't often agree on your specific 
proposals as being too solution-centric.. :-)

> "dual-stack". Would "dual protocol network" be more appropriate name?</MB>

Dual-stack is a well-established term already (IMHO), so using that is 
probably preferable.

> Suggesting to s/configured tunnels/negociated tunnels/g  throughout the text

"negotiated" is misleading, as it's possible that the tunnel requires 
no negotiation all (see STEP).

I haven't been able to find a good term either -- as a working term, 
I've used "(zero-)configured tunnels" a few times, implying that 
setting up something like that doesn't *have* to require any 
configuration.

It would be nice if someone could come up with a good term here..

>    of support or infrastructure for IPv6 in the local or remote ISPs.

No, I believe this is misleading.  Tunnel-brokering -like solution 
requires more infrastructure than 6to4 or Teredo.  So you can't say 
these solution aim to work with a minimal amount of infra in the local 
or remote ISPs.

However, some rewording to take account the (upcoming) results of the 
"zero-configured" discussions should probably go in here.

> "However, automatic tunnels and negociated tunnels are easier to

This is incorrect, IMHO.  All the traffic goes through the tunnel 
endpoint with a bidirectional tunneling, only some with automatic 
tunneling.

> <MB> Is "direct path always possible in all cases between Teredo nodes?

It isn't and this should be reflected here.

> Suggesting: s/The associated costs can be significant// 

Both models for "3rd party infrastructures" have disadvantages for all
of 6to4, Teredo and tunnel broker.  But these are different. This
needs to be discussed more.

For 6to4 and Teredo?, the users don't use your IPv6 prefix, just your 
bandwidth for non-direct traffic.

For tunnel broker model, people both use your prefix (think of abuse 
reports, etc.), and use more of your bandwidth (depending on how much 
of the traffic could be direct) as well.

> <MB> s/"native" host/"native host or another host using another automatic

True, but this should probably include text about local relays as 
well.

> of several parallel IPv6 Internets.

With some rewording, this could be added.

> Suggesting: s/cover "almost all"/cover all/.

Whether the solution must cover absolutely every NAT model or not is 
certainly a tradeoff to consider.  Depends on the deployment model.

> scope of the unmanaged network scenario and only work for a single node

Good point.

> negociated tunnel over IPv4 in the absence of NAT and negociated tunnel

In case we really want to go down this rathole, this should list at 
least STEP as well.  The reason why 6to5/Teredo were mentioned that 
there is no other proposals in that area, and the question is not 
about the technology as such but whether it is needed in the first 
place.

> s/An automatic solution like Teredo appears/Teredo and TSP appear/

Would you appreciate your tunnel broker address being glued into 20 
million nodes, all of them contacting you for an anonymous tunnel, and 
would put their traffic over your links?  It's not feasible as such.  
This is why we need to understand the "opportunistic" requirements 
better.  The text should be tuned, but the right language will not be 
as simple as you propose.

> teredo and 6to4 and the security considerations of those relays. 

Yep.

> relay for dns requests/answers. DNS request go directly from node to

IMHO, you certainly can't assume that your DSL box will act as a DNS 
"forwarder", but if it does, it will be protocol-independent.  I think 
the text above needs to be tuned to be in line with that.. a lot as 
you say.

> addresses as part of the establishment of the tunnel.

The TEP configuration is not releant here, but the reverse tree
delegation could be.  I'm not sure where this would fit best. A
slightly different wording would probably be useful.

>  (and remove the "alternative way" sentence.

I agree with your first points, but I don't agree with your wording 
suggestion -- it doesn't cover the different issues at sufficient 
detail.

>  might support 6to4 or TSP/

I agree that this kind of language should probably be tuned a bit.

> Suggesting to remove the sentence "The tunnel broker ... configuration".

I think you misunderstood the point.  How can the user discover which 
tunnel broker to use?  Browsing the web?

The point is that for Tunnel Broker to be usable more widely, there 
has to be a "discovery function" which can be coded in by the 
*vendors* which then finds a good tunnel broker.  Gluing in the 
freenet6 broker address is a non-starter for a couple of dozen million 
hosts ;-)

> a ubiquitous way to provide v6 in v4 with or without NAT and v4 in v6. 

There are no standardized solutions, which is what it says.  Moreover, 
I don't think people have even stopped to think for very long what's 
actually needed here.

Some text about current solutions of approaches should probably be 
included though.

> configured tunnels with NAT traversal[TSP] and IPv4 in IPv6 tunnels

Disagree with this.

> Suggesting to delete 4- since text is added in 1- for that purpose.

IMHO, 4) should stay, for reasons described above.

> <MB>a discussion and reference to draft on security of relays should

There is no such draft unfortunately.  (on 6to4 security only)

> Work in progress, draft-blanchet-v6ops-tunnelbroker-tsp-00.

Might be useful for Informative section, but not in Normative, I 
think.

> to find the documents</MB>

Might not hurt, but would have to update them too then ;-)

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