[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-suryanarayanan-v6ops-zeroconf-reqs-00
Hi,
Some comments on this draft. Overall I found it seemed overly long,
it meandered somewhat and lacked some focus, and included a number of
repeated chunks of text that could be saod in one place.
Zero-Configuration Tunneling Requirements
draft-suryanarayanan-v6ops-zeroconf-reqs-00.txt
>> Main comments:
>> 1. Not clear what scope is, e.g. single node or not, within the
network of a single provider or not, is host-host zct supported
or not, etc.
>> 2. Should state assumptions in one place/section, they are split
across the document in many places. This would include the
two items in the "out of scope" appendix.
>> 3. Should list all requirements in one section and have the four
scenarios refer to that, at present some scenarios have their
own (sometimes repeated) requirements.
>> Specific comments:
1. Introduction
One of the major differences between the zero-configuration tunneling
mechanism and the full-fledged tunneling mechanism is that the former
does not support user authentication, which should not be an issue
because the scope of the users of this mechanism are already users of
the Service Provider actually deploying it. Consequently, the users
are to be authenticated by other means, which are out of the scope of
this document.
>> Thus this zct solution is only for intra-provider solutions? Just
state that if it's the case.
>> Is this a solution for single nodes only? If so, state that clearly
early on.
It should be emphasized that unless otherwise specified, in this
document the reference, IPv6-in-IPv4 encapsulation as defined in [7],
refers to the aspects of Protocol-41 encapsulation related to IPv4
header construction (except for source and destination address
determination), MTU and Fragmentation, Hop Limits and ICMP handling
as detailed in Section 3.1-3.6 of [7]. The particular aspects of
Configured IPv6-In-IPv4 Tunneling in the areas of IPv4 source and
destination address determination, tunnel link characteristics and
IPv6 Neighbor Discovery operation are not intended referred to by the
above reference.
>> This is a very clumsy paragraph.
This document only identifies requirements for a zero-configuration
tunneling mechanism, based on which solutions can be developed or
identified.
>> Also misleading - do you mean the requirements are driven by the
available solutions?? I assume not, so it needs rewording
2. Terminology
Zero-Configuration Tunneling site: A logical IPv4 network over which
IPv6 connectivity is provided to dual-stack nodes by means of
Zero-Configuration Tunneling.
>> Seems to also be a single-provider IPv4 network?
Tunnel End-Point (TEP): A dual-stack node performing IPv6-in-IPv4
tunnel encapsulation/decapsulation in accordance with
Zero-Configuration Tunneling.
>> "in accordance with zct", but zct is not defined in this section?
Tunnel Server (TS): A dual-stack server node with IPv6 connectivity
and which provides IPv6 connectivity to client nodes by performing
IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from client nodes
in accordance with Zero-Configuration Tunneling. A Tunnel Server is
likely to be a dual-stack router.
>> "with IPv4 and IPv6 connectivity"?
Direct Tunneling: Direct tunnelling here refer to the case where
end-hosts located within the same Zero-Configuration Tunnelling site
may circumvent the Tunnel Server and communicate directly using the
tunnel protocol.
>> Somewhere in this document do we need to comment on IPv4 compatible
addressing, which is a form of zct? These have been deprecated,
but may (or may not!) be a solution to this requirement set?
3. Applicability
Zero-Configuration Tunneling does not attempt to provide emulation of
the full set of native IPv6 connectivity functions as defined by [8],
[9] and [10]
>> You're jumping into wider comments without yet saying what the zct
should provide? I think you should spell out what the requirements
are first? (Which is in Section 6, so maybe put this text there?)
It is possible that the same zero-configuration Tunneling mechanism
can be used in various deployment scenarios. However, it is not
required that same tunnel set-up protocol be deployable in all
scenarios.
>> But we'd prefer one solution, so a node in different environments can
use a single solution?
4. Limitations
4.1 IPv6 address allocation, Scope and Limitations
It is not explicitly within the scope to support privacy extensions
to IPv6 [11].
>> Do you mean there is no requirement to support it? If so, just say so.
It is not explicitly within the scope to support usage of IPv6
multicast.
>> Ditto. (Though that is disappointing)
4.2 IPv6 tunnel link characteristics, Scope and Limitations
Direct tunneling is neither an explicit goal nor explicitly excluded
in Zero-Configuration Tunneling.
>> Ditto.
It is not an explicit requirement for the zero-configuration tunnel
link to support IPv6 link-local multicast.
>> Is that going to cause problems? Perhaps clarify this.
The tunnel protocol should allow for the formation of a link-local
address on the tunnel link, though no particular usage of such an
address is explicitly demanded by the goals set forward here.
>> Do you need the words after the ","?
5. Basic Assumptions and Prerequistes
Zero-configuration Tunneling is a simple mode with no user
registration, essentially deployed in a controlled and
"authenticated" environment where the service is made available to
all the IPv4 customers.
>> s/essentially/typically?
o The user is being authenticated to the network by means external
to the tunneling protocol.
>> But this solution can be used in open networks? Or only authenticated
access ones?
The following assumption is only valid for basic requirements where
there is no NAT in the path.
o The Zero-Configuration Tunneling network is fully penetrable for
intra-site IPv6-in-IPv4 Protocol 41 traffic.
>> Earlier you said "the tunnelling mechanism in [7]"... say that here or
do you need to explictly specify proto-41? (Just be consistent)
It is a prerequisite that the tunnel protocol must work in IPv4
network environments where IPv4 multicast is not provided.
6. Requirements for Zero-Configuration Tunneling Mechanisms
6.1 Basic Requirements
The basic requirements described below must be supported by any
zero-configuration tunneling protocol. Tunneling protocol satisfying
these basic requirements could be used in a deployment scenarios
which is NAT-free, does not require IPv6 /64 address or prefix
delegation.
>> The second sentence should be broken out into explicit assumptions
or requirements. Do you mean there should be no NATs between the
client and tunnel server (or must not be)? Do you mean the requirement
is to only support /128 tunnels? How does prefix delegation relate
to a node-based mechanism?
6.1.1 Simplicity
The tunnel protocol is easy to implement in the targeted environment.
Additionally, the protocol should provide a reasonable,limited set of
basic IPv6 connectivity features
>> What are these "reasonable, limited" features?
6.1.2 Automated IPv6-in-IPv4 tunnel establishment
The mechanism must be fully dynamic in the sense that it must not
require IP address information such as the IPv4 address of a Tunnel
Server and/or the IPv6 address(es) to use for IPv6 connectivity to be
configured on the Tunnel Clients beforehand.
>> So you mean automatic not dynamic? If so, state that tunnel endpoint
discovery is required, but is out of scope of this document.
6.1.3 IPv6 Address Assignment and Prefix Delegation
Prefix Delegation support is dealt with respect to various deployment
scenarios in sections 6, 7, 8 and 9. It is not however required that
any tunneling protocol supporting only basic requirements provide
support for prefix delegation.
>> I'm not clear why you'd want to do prefix-delegation to a node?
Or is zct to be applied to links as well?
It is preferable that the address assignment provides a stable
address, that is, an address that can be used for IPv6 connectivity
for a certain amount of time rather than solely one address per
higher layer session initiation
>> A bit clumsy, just delete text after the ","?
>> Do you mean the same address on reconnection later? If so, how do
you do that without use of authentication, cookies or similar?
6.1.5 Tunnel Server End-Point Discovery
In order to offer "plug and play", the implementation should allow a
mechanism to discover the address of the tunnel server that will
provide the tunnel connectivity. This discovery should be automatic
within a Service Provider's network.
>> Again state TEP discovery mechanism is outside the scope of this doc?
Or is it not? If you state it's required, a pointer to more info is
needed.
6.1.7 Private and public IPv4 addresses
The tunnel protocol must work over IPv4 sites deploying both private
and public IPv4 addresses.
Furthermore, the tunnel protocol should work with both dynamic and
static IPv4 address allocation.
>> What does this mean, in practice? Do you mean the zct method should
support the IPv4 address changing while the tunnel is up?? If you
mean to get the same IPv6 address when reconnecting on a new IPv4
dynamic address on a new session, how do you do that without any
authentication?
6.1.8 Scalability and Load-Balancing
This may be achieved using load balancing functions provided by the
Tunnel Server End-point Discovery mechanism as detailed in [13].
>> So now you add a pointer to the TEP text; this is needed earlier also.
6.1.9 Easy to deploy and Easy to Phase Out
Once IPv6 is available natively in the access network, it should be
easy to phase out the tunneling protocol.
>> Two subtle different meanings to "should" here... :)
6.2.1 Tunnel Link Sustainability
In certain environments, like in 3GPP, to minimize the overhead and
latency associated with tunnel initialisation, it is highly desirable
that tunnels remain active for a large amount of time, ideally
infinitely. In such environments, the tunnel protocol must not
mandate keep-alive messages to be transmitted by the host simply in
order to sustain tunnel link connectivity.
>> Presumably in a no-NAT environment such keep-alives are not so
necessary. Some tunnel brokers use heartbeats to allow reconnection
with the same (address) parameters. Maybe that's beyond zct scope.
6.2.2 NAT Traversal
The Tunnel set-up protocol must be able detect the presence of one or
more NATs in its path. It must be able to adapt to the following
cases, by choosing the most optimal tunnel encapsulation depending on
the presence of a NAT.
>> But above you said no-NAT environments? Which is it?
>> Are you saying NAT traversal must be supported?
6.2.3 Firewall Traversal
Even if no NAT is in the tunnel path, there may be a firewall which
prohibits proto-41. In such case, the tunnel encapsulation selection
based on NAT detection will select a tunnel that will not work.
>> Doesn't that depend on the specifics of the detection mechanism?
The implementation must allow a user to explicitly specify the
desired tunnel encapsulation, regardless of the NAT detection
process.
6.2.4 Extensibility
The protocol must be extensible to support tunnel encapsulation other
than IPv6 in IPv4 and IPv6 in transport in IPv4. In particular,
encapsulation of IPv4 in IPv6 or IPv6 in IPv6 could be defined.
>> "must be" or "could be" - decide :)
6.2.5 IPv6 Address Stability
[This section shall be removed after getting more opinions from
others.]
The IPv6 address is "transient" and may change, but the protocol
should offer a mechanism to provide IPv6 address stability (e.g.
cookie mechanism). The implementation of this mechanism must allow
this feature to be turned off.
>> You already mentioned this earlier. Just do it in one place?
8. Unmanaged Networks Specific Requirements
An unmanaged network is where no network manager or staff is
available to configure network devices.
>> No need to state what it is, just cite the unman-scenario text,
which you do just below, so delete this.
Zero-Configuration Tunneling
Protocol is quite useful in this context where automation of IPv6
connectivity to first-hop ISP and prefix assignment is handled.
Unmanaged Networks [3] may or may not be behind a NAT.
A zero-configuration tunneling mechanism should satisfy the basic
requirements (see section 6.1) and should take into account the
specific requirements described below.
8.1 Address Assignment and Prefix Delegation
In unmanaged networks, assignment of an IPv6 address (/64) to the
end-node must be supported.
>> OK, so it isn't a node-based mechanism. Get the text at the start :)
8.2 NAT Traversal
The implementation must provide an option to to turn on extra
encapsulation manually.In order to assure interoperability, at least
one common tunnel encapsulation type must be supported.
>> Are you going to name one?
8.3 Firewall Traversal
As indicated in section 6.2.3, the tunneling protocol must be able to
work in networks where the firewall prohibits proto-41 packets.
>> But firewalls implement policy, and won;t that policy prevent other
types of tunnelling?
9. Enterprise Network Requirements
In an enterprise network where IPv4 is dominant, a tunneled
infrastructure can be used to provider IPv6 services to the IPv6
islands (hosts or networks) inside the enterprise, before a full IPv6
native infrastructure is built. Zero-Configuration tunneling
protocol can be used to give IPv6 connectivity and prefix information
for the islands. This gives to the enterprise a basic deployment of
IPv6 while maintaining automation and permanence of the IPv6
assignments to the islands.
>> Isn't this unlikely? Wouldn't the network administrators prefer a
structured and managed deployment method?
In cases where the network administrator is sure about the absence of
internal NAT and firewalls in the network, and end-nodes will need
only IPv6 /128 address, a tunneling protocol satisfying only the
basic requirements will suffice.
>> And there's no need for IPv6 address stability, or extensibility in
the network (to be consistent with 6.2)
A zero-configuration tunneling mechanism should satisfy the basic
requirements (see section 6.1) and should take into account the
specific requirements described below.
>> Why are they below and not just in section 6?? The requirements
are being repeated in the scenario sections, bloating the text.
9.4.1 IPv4-in-IPv6 Tunneling
The tunneling Protocol should be able to handle automatic
establishment of IPv4-in-IPv6 tunnels. It must be able to handle
assignment of temporary IPv4 address and other tunnel parameters as
required.
>> This is a new one, and only suggested higher up in the doc, I
would cite it as an advanced requirement?
10. ISP Network Specific Requirements
In a scenario where connection to customer from ISP supports both
IPv4 and IPv6, but the customer has IPv6-only network and the ISP
backbone is IPv4-only, IPv6 packets from customer needs to be
tunneled over the IPv4 backbone to the next upstream ISP.
Zero-configuration tunneling mechanism can be used in such scenario
as well.
>> So it's being used for a whole network here, not a node?