Comments on draft-palet-v6ops-tun-auto-disc-02

[Tim Chown <tjc@ecs.soton.ac.uk>]

A good document.

- I think requirements could be spun out to a separate section.

- I think reverse DNS method(s) should be considered.

- Intra-enterprise could be a 5th scenario.



         Analysis of IPv6 Tunnel End-point Discovery Mechanisms
                 draft-palet-v6ops-tun-auto-disc-02.txt


   Tunneling is commonly used in several IPv6 transition mechanisms.  To
   be able to automate setting up tunnels, one critical component is
   being able to automatically determine the tunnel end-point for the
   tunneling mechanism.  This memo analyses the different approaches for
   configuring the IPv6 tunnel endpoint on a node.

>> To be pedantic it is methods to determine the remote IPv4 address of
   the tunnel?

1.  Introduction

   One critical piece in the automated set-up is discovering the
   end-point for the IPv6-in-IPv4 (or possibly in the future,
   IPv4-in-IPv6) tunnel.  Note that the other end-point ("tunnel
   server") typically also needs to have a means to configure the
   client's end-point, but that is assumed to be transition mechanism
   specific, and beyond the scope of this memo.  A solution is being
   designed [1] based on the tunnel server/broker concept [2] which
   will, in particular, require this kind of discovery.

>> Should you mention such solutions in this document?

   Many already-specified mechanisms already include a form of
   auto-discovery: for example, 6to4 [3] uses global anycast [4] and/or
   vendor's branch of DNS, Teredo [5] uses vendor's branch of DNS, and
   ISATAP [6] uses search-path -prefixed DNS.

>> You should probably use a clearer phrase than "vendor's branch of 
   DNS" here.

2.1  Scenario 1: Initial IPv6 Deployment Stage

   If this kind of IPv6 connectivity is set up automatically, it could
   create a load on the ISP's equipment which is configured as the
   tunnel-endpoint (e.g., a tunnel server).  This is particularly
   important if state needs to be maintained.  To address this
   consideration, the discovery method should allow for multiple
   end-points within a domain or even including a load-balancing
   mechanism.

>> Should such requirements be split into a separate section?

2.2  Scenario 2: Initial IPv6 Support from External ISP

   Given the fact that IPv6 service could be offered by third parties,
   some kind of authentication could be required in order to allow only
   registered customers to use the IPv6 service.  The authentication
   method will depend on the transition mechanism, so it is out of scope
   of this memo.

>> But it is another (optional) requirement to split off (or at least
   summarise in a subsequent section).


2.3  Scenario 3: Nomadic Users


   Nomadic users require connectivity to Internet from everywhere, from
   different locations: meetings, conferences, holidays, etc.  Under
   this circumstance (always) obtaining native IPv6 connectivity is not
   feasible.  The user has two choices: to discover a local tunnel (with
   different IPv6 addresses and prefixes) if provided by the local ISP,
   or to connect to the "home ISP" or "home network", implying the
   possibility of keeping the same addresses.

>> I'm not clear that nomadic users should be any different from case
   2.2 (the 3rd part ISP)?
 
   A local tunnel is typically a preferable choice, and could also be
   used as a Mobile IPv6 [7] care-of address.  However, in many cases,
   the local ISP may not be providing a tunnel service.

>> No need to mention MIPv6 here, just delete that?

   Connecting to a "home provider" to obtain the tunnel is typically a
   safe choice, provided that the "home provider" allows IPv4 addresses
   outside its own domain to use its tunnel services; at the very least,
   typically this will require some sort of authentication.  However,
   especially when roaming on a different continent as the home network,
   the latencies, etc., may be undesirable, so one might want to keep
   this only as a backup option in case other approaches fail.

>> Minimising latency may be another requirement to split out.

   The whole process for having a new IPv6 tunnel with a new provider
   should be as transparent as possible in order to avoid that users
   need to manually re-register or change the configuration in their
   host.  It would be desirable that the architecture enables the users
   to get connected and re-connected to the nearest tunnel end-point
   without manual intervention (for example when moving).

>> As is transparency in the mechanism (but that may be hard if explicit
   authentication is needed).

2.4  Scenario 4: Advanced IPv6 Deployment Stage

   When the IPv6 deployment is in a more advanced stage, namely more
   users in more places looking for IPv6 connectivity, it is possible
   that ISPs providing IPv6 connectivity need to start a broader
   deployment.  For a best IPv6 service, it is feasible that they
   increase the performance by using a tunnel end-point cluster
   geographically distributed to cover a country, etc.  Furthermore they
   could offer the users only one of the methods proposed below for
   accessing the IPv6 connectivity.  Each time users get IPv6
   connectivity, they could use the same accessing method but they could
   be assigned to different tunnel end-point belonging the cluster.

>> Isn't this just restating the laod-balancing requirement? 

   Under this schema, some kind of load balancing could be required in
   order to distribute the load among the ISP resources.

>> Aha yes it is :)

   In order to let all the candidate tunnel end-points to know the
   configuration of the previous user's tunnels, some kind of tunnel
   management should be defined.  However it is strongly dependant on
   the transition mechanism used, so it is out of the scope of this
   document.

>> But it is a requirement to note.   Identifying users is also useful
   e.g. in the case of heartbeat protocols that detect when the same
   user reconnects with a different (e.g. dynamic on their SOHO DSL
   network) IPv4 endpoint address.

>> So in fact there are now four scenarios, not the three you stated at
   the start of this section?

>> Is there a case also for TEP discovery in intra-site sparse IPv6 
   (dual-stack) deployment also in the enterprise?  (e.g. that which is 
   currently done by some by isatap and the isatap router)

3.2  Centralized Broker-based Solutions

   The selection of the proper TEP would be based on information about
   TEP loads and network metrics collected by several ways, such as RTTs
   measured by network probes, routing protocol information, and so
   forth. 

>> These are more requirements to split out/ add to the requirements 
   summary?

   The user will need to connect to the selected TEP either by
   using the DNS system, when the client tries to resolve the host name,
   or by mean of whatever other mechanism defined, which possibly will
   require an specific code implementation on both centralized server
   and clients.

>> So this is similar to how a web servers may be geographically
   distributed?

   3.  It can require the installation of specific software on both
       centralized server and clients to negotiate the proper TEP.

>> But you need specific software anyway for the authentication on TSP,
   if you use TSP?

   Therefore, when evaluating the solutions, it will be important to be
   able to contrast the real benefits of the solution vs the drawbacks.

>> Are you doing this? :)

3.3  DNS-based Solutions

   1.  "global name": the systems look up a globally unique name, like
       www.tunnel-server.net.; this could be applicable with
       (unfeasible) global inter-domain broker or anycast-based
       solutions, and is therefore not considered at more length.

>> You also mentioned this above too in 3.2?

   3.  "prefixing the search path" [10]: one could look up a
       service-specific special string, like "_tunnel-server", appended
       by the DNS search path, e.g., "isp.example.com", resulting in a
       query of "_tunnel-server.isp.example.com".  This assumes that the
       DNS search path is provided by the ISP, and used by the user;
       this applies to most users (advanced users may have their own
       domain names, own DNS servers, etc., but those could be expected
       to manually configure the end-point information).  This is the
       most interesting approach, explored at more length below.

>> I share Alain's concerns on this.

3.3.1  Prefixing the DNS Search Path

   Another consideration is the deployment of wildcard DNS records.  If
   A/AAAA records were to be used, such records might create false
   positives quite easily.  Fortunately, wildcards are commonly deployed
   only for MX records.  A benefit of using SRV records is that they use
   an additional level in the zones, like:
   _tunnel-server._udp.isp.example.com."; this would prevent a wildcard
   record "*.isp.example.com" from harassing the discovery of the
   end-point.  XXX: needs to be checked.

>> Has this been confirmed either way?

3.4  DHCP-based Solutions

   o  It requires manual configuration/update of the ISP's DHCP servers
      when there are changes to the tunnel end-points, similar to
      updating DNS, NTP, etc., servers.

>> But this is true of any method?

>> There seems to be more detail on SLP than other methods?   Should
   this level of detail be balanced?

>> What about reverse DNS methods?