Subject: Comments on draft-suryanarayanan-v6ops-zeroconf-reqs-00

From: Tim Chown <[email-masked]>
Date: Sun, 7 Nov 2004 23:48:37 +0000

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?

---

From: Radhakrishnan Suryanarayanan <[email-masked]>
Date: Mon, 08 Nov 2004 11:07:30 +0530

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

---

From: Tim Chown <[email-masked]>
Date: Mon, 8 Nov 2004 16:46:53 +0000

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

-- 
Tim

North American IPv6 Task Force Technologist Seminar
More info at http://www.ipv6seminar.com/