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

[Pekka Savola <pekkas@netcore.fi>]

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

On Fri, 27 Feb 2004, Marc Blanchet wrote:
>    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>

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

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

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

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

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.

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

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

>    In automatic tunnels like [Teredo] and [6to4], the bulk of the
>    traffic between two nodes using the same technology is exchanged on
>    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.
> 
> <MB> Is "direct path always possible in all cases between Teredo nodes?
> </MB>

It isn't and this should be reflected here.

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

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.

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

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

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

With some rewording, this could be added.

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

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

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

Good point.

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

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.

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

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.

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

Yep.

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

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.

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

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.

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

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.

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

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

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

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

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

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.

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

Disagree with this.

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

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

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

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

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

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

> <MB>would suggest to add draft filenames in references to make easier
> 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