comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt

[Pekka Savola <pekkas@netcore.fi>]

Hi,

A couple of comments on
draft-palet-v6ops-solution-tun-auto-disc-00.txt.  In short, this seems
like a start in narrowing down the list of methods given in
draft-palet-v6ops-tun-auto-disc-01.txt, but there are two problems
with this: 1) IMHO it isn't yet sufficiently far narrowed down ;-),
and 2)  the draft doesn't sufficiently describe the
mechanism/protocol/implementation requirements, and how those
interoperate with whatever the ISPs would deploy.

substantial
-----------

1) the most fundamental issue I see with this draft builds on text in
section 4 about what is the mandatory-to-implement mechanism and what is
not.  That's important.

There are two perspectives here: 'mandatory to implement' in the specific
service (e.g., 6to4, TSP, Teredo, ISATAP, etc.), and 'mandatory to deploy'
in the ISP.

I think you've only focused on what the ISP should deploy.  You'll also need
to discuss what should be mandatory to implement in the
protocols/mechanisms, because this is where interop problems happen.

(I.e., I think the document too much deployment-centric, not focusing
sufficiently on what must be implemented and how that would operate with
different modes of deployment.)

My fundamental concern is that if you say "ISP can implement any of the
proposed approaches, or preferably all of them", that means that for a
mechanism to be interoperable with what the ISPs are offering, the
mechanisms/protocols would need to implement EVERYTHING.

And that seems like a potentially bad tradeoff to me.  The fewer
autodiscovery mechanisms there are, the fewer combinations there are that
something would not work.

For example, if we just specified DNS lookup in a certain way, the ISP would
only have one way to deploy it and the mechanism one way to implement it,
and interoperability would be guaranteed.

"Less is more" ;-).  The current draft is IMHO not a clear solution.  It's a
"kitchen sink" description of best solutions, which may or may not work
together, and it may or may not be possible to get a well-interoperable
mechanism out of it.  I'd try to narrow down the number of different
discovery mechanisms used as much as possible.

2. Section 5.4 seems to be proposing using dual-faced DNS towards the
Internet vs own customers to control the visibility of the TEP addresses in
the DNS.  This seems completely wrong direction to take, because the
addresses will still be available even if they are not made available in the
public DNS.

The last paragraph says it all: it would be much better to forget about
dual-faced DNS completely in this context, and just perform filtering for
the service.  It offers complete solution to the "theft-of-service"
problems, and is easier and more correct way to deploy to boot.

So, please remove dual-faced DNS, unless there are some very strong unstated
assumptions what benefits it gives instead of just filtering (and state
them).

3. In section 7, you mention alternative DHCP-based solution.  Because the
people not familiar with the tun-auto-disc background will first ask "why
not just use DHCPv4 and forget about everything else?", this section
probably needs to include much better justification (to be gathered from
the tun-auto-disc document, for example) why it's not the main proposal.

Heck, it might even make sense to put some text, or at least referral to
section 7, in the introduction.


semi-substantial
----------------

   On the other hand, shared anycast is also a very useful approach
   since it can globally identify a specific service (TEP or transition
   mechanism).

==> I think you're assuming that anycast (shared-unicast) would be allocated
an interdomain range, because otherwise it can't be globally identified. 
This doesn't need to be the case.

   For example the records for 6in4, tsp, teredo, isatap and 6to4 would
   result: 6in4_srv.ispname.com, tsp_srv.ispname.com,
   teredo_srv.ispname.com, isatap_srv.ispname.com, 6to4_srv.ispname.com,
   etc.
                                                                                                                                          
==> you forgot the protocol (_tcp, _udp, etc.) which you had in the examples
below?

Also, did you find a source where "_ipv4" protocol comes from?  Is there an
example of this being used somewhere, or did you just make it up? :-)

   Note: The use of the underscore character minimizes the probability
   of conflict with DNS names already defined.

==> this belongs at the end of section 3.2, rather than at the end of 3.3,
or..?

   To do that, the ISP's domain name is essential for prefixing the DNS
   search path, so the client (or rather the operating system) firstly
   learns the domain name of the ISP.  There are several ways to do it,
   but in general it will be learned by making NS RR queries to the DNS.

==> You have assumptions in the last sentence, that the user looks up the IP
address and its corresponding NS records to get the domain name.  That's
certainly one approach.  But as currently deployed, folks just depend on the
DNS search path.  So, I think the last sentence needs to be expanded or
removed.

the client (rather the operating system)
   makes a DNS query [6][7] for QNAME=teredo_srv.ispname.com, QCLASS=IN,
   and QTYPE=A or QTYPE=CNAME.

==> which QTYPE is it?  Are you saying the implementations need to query
both?  That's not good.  Note that if you do a QTYPE=A query, that should
also match CNAME and give the A record in the answer section, so there is no
need to query CNAME explicitly.  Try e.g. 'dig aaaa ftp.ipv6.funet.fi'.



editorial
---------

   4.  It is topologically correct: Provides the nearest TEP to the user
       in terms of hops.

==> for the sake of clarify, please expand 'hops'.

   However anycast routes not always are well configured and stable, so
   connection with the server belonging to an anycast group could not be
   always possible, which means that is not necessarily the most
   topologically correct.

==> s/could/might/ ?

The DNS will redirect to a TEP (or alternatively a TB
   more sophistication is required) located within the ISP or a third
   party (other near ISP, roaming TEP service, etc.)

==> s/TB/TB if/ ?

   The solution consequently, makes use of existing protocols, not
   requiring modifications or any new protocol.

==> remove ','.

   When looking for a specific TEP within the ISP the user belongs to,
   the first step is always the same because the user does not know (and
   neither has to know) which is the transition mechanism deployment
   status within its ISP, so the user always query firstly for a DNS SRV
   RR to its ISP DNS server.

==> you say 'user', but you probably referred to the application/stack ?

   the ISP DNS server.  To discover the specific TEP within the ISPb@Ys
 
==> some corrupted chars around 'ISP'.

It is also possible that
   ISPs are interested to offer IPv6 transition mechanisms by means of
   third party agreements or even through well know and convenient near
   TEPs which are for free.

==> some rewording near the end..

   This section list de transition mechanisms and the service names to
 
==> s/list de/lists the/ ?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings