[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-suryanarayanan-v6ops-zeroconf-reqs-00
Thanks.
Having looked through the new draft, I don't think the generic points have
been addressed, though some of the more minor ones may have been.
I guess we need some strategic discussion on the way forward on Wednesday,
as to how/if the documents combine and what solutions/timelines are
realistic/pragmatic.
Tim
On Mon, Nov 08, 2004 at 11:07:30AM +0530, Radhakrishnan Suryanarayanan wrote:
> 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?
> >
> >
> >
--
Tim
North American IPv6 Task Force Technologist Seminar
More info at http://www.ipv6seminar.com/