[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-suryanarayanan-v6ops-zeroconf-reqs-00
Hi Tim,
Thanks a lot for your comments.
I will reply to your comments in detail ASAP. In the meantime, may i
request you to look into the revision 01 for the draft
http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt
This draft is derived from non-registered mode discussed in the previous
assisted tunneling requirements and partly from 3gpp-specific ZCT. Hence
those identical chunks of text in places.
A reason for putting requirements under the scenario-specific is because of
the need in some places
related to making some of the requirements "must" or "should" from "should"
or "may".
Nevertheless, there is lot of scope to improve the document and i shall try
my best to do it. :)
>(In theory, draft-suryanarayanan-v6ops-zeroconf-reqs-00 could/should
>list all the requirements, and each of the 4 scenario sections - 3gpp,
>isp, unman, enterprise - should point at which requirements they carry?)
Ideally a single draft should be sufficient.:)
>Will we thus see more simialr docs for unman, ent and isp?
Definitely NOT. 3GPP is just one off case because of its timing
requirements.
Thanks & Regards
Radhakrishnan
----- Original Message -----
From: "Tim Chown" <tjc@ecs.soton.ac.uk>
To: <v6ops@ops.ietf.org>
Sent: Monday, November 08, 2004 5:18 AM
Subject: 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?
>
>
>