[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt
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>