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

From: Pekka Savola <[email-masked]>
Date: Mon, 18 Oct 2004 09:41:13 +0300 (EEST)

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 21 Oct 2004 19:29:45 +0200

Hi Pekka,

Sorry, too busy the last days ;-)

Thanks a lot for your comments.

See my comments in-line below.

Regards,
Jordi

> De: Pekka Savola <[email-masked]>
> Responder a: [email-masked]
> Fecha: Mon, 18 Oct 2004 09:41:13 +0300 (EEST)
> Para: [email-masked]
> Asunto: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt
> 
> Hi,
> 
> A couple of comments on

Our view is that if we want a resilience solution, we need some
complementarily between DNS and anycast. It can be done just with DNS, but
then it will work only within the ISP.

In our opinion we need a solution that works also outside the "customer"
ISP.

> interoperate with whatever the ISPs would deploy.

I'm not sure what do you mean here, but providing more details about DNS SRV
RR and anycast seems to us out of the scope of this document. There are no
_new_ requirements for the ISP, neither the client, because we are using
existing mechanism (DNS and anycast).

> substantial

I think you're missing somehow the point. We are trying to do in such way
that no modification is required for the existing transition mechanisms.
Instead, the Operating System will require to replace the actual defaults
for the TEPs (6to4, Teredo, etc.), which the name to be defined by IANA as
part of the process of getting this document further.

> discovery mechanisms used as much as possible.

We are using a single name for each protocol, so whatever is implemented in
the ISP, will work for the client. I think this provides complete
interoperability !

> assumptions what benefits it gives instead of just filtering (and state

Our intend here is to offer two options:
1) No service at all outside the ISP (then filtering will make it)
2) An ISP that offers services (some, may be not the same) to users outside
its own network. I think this is a possibility and we must support it in a
clear way, in case somebody want to make use of it.

We can further clarify it in the document probably (working on a new version
right now).

> the tun-auto-disc document, for example) why it's not the main proposal.

We wanted to avoid duplicating text from the requirements document ;-)

> section 7, in the introduction.

Ok. Will do it.

> semi-substantial

Our intend is to use the same prefix as for 6to4, for all the mechanisms (so
we can allocate for example up to 254 new mechanisms, more than enough).

> ==> you forgot the protocol (_tcp, _udp, etc.) which you had in the examples

Yes, we discovered already after sending the draft, that was a mistake
forgetting the protocol sequence.

> example of this being used somewhere, or did you just make it up? :-)

In the SRV RR description is not indicated that ipv4 could be used, but is
also not explicitly excluded, so should be an option. In fact, if the
mechanism is used for autodiscovering IPv6 TEPs (when you want to tunnel
4in6, for example), it will be possible to use ipv6.

Actually, anyway, all them are possible examples, and in the case of TSP, it
could be also _udp, _ipv4, _ipv6, etc.

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

Actually this belongs to the complete section 3.

> DNS search path.  So, I think the last sentence needs to be expanded or

We are not referring to the IP address, but to the search path, as you say,
so ?

> need to query CNAME explicitly.  Try e.g. 'dig aaaa ftp.ipv6.funet.fi'.

No, just query one of both, the one the OS prefers ;-)

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

IPv4 hops if looking for an IPv4 TEP (to gain access to IPv6).

>  always possible, which means that is not necessarily the most

Ok.

>  party (other near ISP, roaming TEP service, etc.)

Right.

>  requiring modifications or any new protocol.

Ok.

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

Right.

> ==> some corrupted chars around 'ISP'.

Ok.

> ==> some rewording near the end..

Will reword.

> ==> s/list de/lists the/ ?

Some Spanglish went there by mistake ;-)

Should be "list the"

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Oct 2004 09:48:42 +0300 (EEST)

in-line,

> In our opinion we need a solution that works also outside the "customer"

There are a lot of nuances to 'working outside the "customer" ISP', 
for example:

Does the solution have to support complete 3rd parties, such as 
anycasting 6to4 relays now? (Remember that 6to4 relays are stateless, 
while the tunnel servers typically aren't, and this would cause 
additional implications on the mechanisms.)

Does the solution have to support those customers which momentarily 
roam outside of their ISP's access network?  [E.g., as solution based 
on DNS records would probably still be at least partially applicable 
here]

I'm concerned that because there is significantly smaller amount of
incentive, and more technical challenges, for ISPs to deploy an
inter-domain anycast solution for tunnel servers, so that it would not
be actually usable for discovery.

> existing mechanism (DNS and anycast).

No, I didn't mean that, but rather what mechanisms must be implemented 
in the mechanism or the host stack.  I'll try to explain below.

> part of the process of getting this document further.

Maybe I did not write clearly enough, without assumptions.

Whether or not this discovery process is done in the host stack, or 
the transition mechanism, is relatively irrelevant.

However, it is VERY MUCH relevant to this draft WHAT must be 
implemented in the host stack or the mechanism to make these work.

For example, if the host would just implement DNS lookups and the ISP 
just anycast, discovery process should fail.

So, when there are multiple mechanisms, one must specify what is the 
mandatory-to-implement part of them, and how different combinations of 
support in the stack/mechanism interoperate with different 
combinations of support in the ISP.

> the ISP, will work for the client. I think this provides complete

Yes, but you also specify the inter-domain anycast in addition to DNS 
lookups using SRV or A records.

Which ones must be supported in the client?  Which ones in the ISP?  
There are probably half a dozen non-interoperable combinations here.

Maybe your implicit assumption is that the client supports all of 
them: interdomain anycast, DNS with SRV, and DNS with A records, and 
maybe even DHCP to the boot -- and tries them in some particular 
order, and then it would just depend on what the ISP supports.

I don't have that assumption.  On the contrary, I think there must be 
a minimal set of approaches so that 1) very little is required to 
implement & deploy, and 2) there are as few interop problems as 
possible.

> clear way, in case somebody want to make use of it.

I can understand these options, but AFAIK dual-faced DNS does not
offer any better means to achieve 2), while being a lot worse.  Sure,
you can hide the tunnel endpoint (so that it can only be looked up in
the local net) and still keep it operational if you move away from the
network, but that allows a lot of abuse (such as local customers
telling their friends outside the IP address to use for their
tunnels).  Doing dual-faced DNS here would be security by obscurity
and that would not be good.

The only practical solution to the 3rd party case appears to be some 
form of registered mode, i.e., the tunnel endpoint being accessible to 
anyone, but only allowing certain registered users.

> We wanted to avoid duplicating text from the requirements document ;-)

Worthy goal, but something DHCP proponents will jump on :-)

> we can allocate for example up to 254 new mechanisms, more than enough).

Uhh, I didn't quite understand: did you mean 192.88.99.2 for X, .3 for 
Y, .4 for Z, or "similar prefix as for 6to4", like 192.88.100.0/24 for 
X, .101.0/24 for Y, etc.

The former would definitely not work.

> could be also _udp, _ipv4, _ipv6, etc.

OK, it seems that the SRV spec does not allocate a namespace for 
"protocol values" such as _tcp, so if something else than _udp or _tcp 
are used, they just need to be made up in such a manner that they 
don't conflict.

> We are not referring to the IP address, but to the search path, as you say,

If you have the search path, you don't need to make a NS RR query.  
NS RR query would only be needed if you wanted to look up the
responsible party for your IP address.

I couldn't figure out why you mentioned 'NS RR' there, so I made some 
conclusions.  I think the above is clarified if you remove or reword 
the text around NS RRs.

> No, just query one of both, the one the OS prefers ;-)

Uhh, you need to specify better what to do so that it can be done in
an interoperable manner.  Or if you specify you have to query both,
that's OK too, but causes significant issues because it takes 
additional packets and additional latency.

> IPv4 hops if looking for an IPv4 TEP (to gain access to IPv6).

Yes, so s/hops/IP hops/

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 24 Oct 2004 18:45:40 +0200

Hi Pekka,

My comment in-line below.

Regards,
Jordi

> Fecha: Fri, 22 Oct 2004 09:48:42 +0300 (EEST)
> Para: JORDI PALET MARTINEZ <[email-masked]>
> CC: [email-masked]
> Asunto: Re: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt
> 
> in-line,
> 

As explained in the Case Studies section, is up to each ISP to decide if
they want to support external users or not.

> on DNS records would probably still be at least partially applicable

From the users point of view, yes. Of course, users always need to rely into
available services, but if we don't provide this part of the solution, they
will never have it. Providing it, they might have it (up to the providers,
even if a few that with to provide the service).

> be actually usable for discovery.

I don't agree, 6to4 is working, and we are just extending the applicability
of 6to4 to other mechanisms.

> in the mechanism or the host stack.  I'll try to explain below.

Ok. We can work on that in a new section, with concrete examples for
different mechanisms.

> just anycast, discovery process should fail.

Understood now. The client must implement the complete picture, but not the
server. I'm about to finish an updated version of the document, and will
make sure this is clear.

> implement & deploy, and 2) there are as few interop problems as

My point of view is that both the ability to resolve SRV/A and anycast are
already available today in all the clients, so making both as part of the
requirement, will not add actually any new requirements.

I'm not considering DHCP at all. May be need to be further clarified. Is one
more option, but more related, in my opinion, to very controlled networks
where you are sure that DHCP options are relayed. We can even delete this
section if it creates confusion. Thoughts from the WG well be needed here !

> anyone, but only allowing certain registered users.

I'm not really sure about this point of view. Need to think about it. More
opinions from the WG, please ?

> Worthy goal, but something DHCP proponents will jump on :-)

Ok. Now this will depend on what the people think about keeping the DHCP
solution in the document or not ...

> The former would definitely not work.

You're right. I was actually thinking in the option that you describe in
first place, but I now realize that precisely because that problem, we use a
prefix for 6to4, instead of just one address. So need to double-check if we
need to move to the 2nd way, or there is an alternative.

> conclusions.  I think the above is clarified if you remove or reword

Ok, need to double-check and/or will do that.

> additional packets and additional latency.

Yes, you're right. I guess it will be simple to stick to A, if we care so
much about the extra packets. WG opinion ?

Ok.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Oct 2004 10:11:06 +0300 (EEST)

Some comments below..

(Btw, as a couple of subjects were left in as 'waiting for more 
feedback', it would be useful to have some kind of issue tracker or 
web page, summary in the following drafts, or the like to keep track 
of comments which have been submitted but haven't been reflected..)

> they want to support external users or not.

Certainly, but remember that some of the solutions we're discussing 
are 'inter-domain', while some others are not (like ISATAP, a possible 
zero-conf tunneling solution).

These two different kinds of mechanisms do have different kinds of 
requirements for the discovery process: certainly, something like 6to4 
is pretty likely to be completely different than the rest.  But we 
don't need an interdomain solution to 6to4 because we have one 
already...

> even if a few that with to provide the service).

But then you assume that the mechanism you're discovering supports 
this feature, which may not be true ?

My point is, that if the discovery is relatively simple, it could also 
be implemented (with just a couple of dozen or a hundred lines of 
code) in the mechanisms themselves, not a generic 'library' or the 
like.

> of 6to4 to other mechanisms.

You don't have to renumber your network when you happen to switch 6to4 
relay providers, either by manually or because the routing changes. 
That would be inevitable with other kinds of mechanisms.  Therefore 
such an interdomain anycast address would have limited applicability 
IMHO. (Only even marginally feasible if anycast was used just for 
discovery, and unicast used for real communication)

> Ok. We can work on that in a new section, with concrete examples for

OK.

> server. I'm about to finish an updated version of the document, and will

Good to make it clear.

FWIW, I personally aren't that fond of the requirement that the 
protocols/mechanisms would have to implement everything -- because 
that would add complexity, and might have significant disadvantages 
(e.g., relating to the latency of the set-up, if you have to try e.g. 
3 different methods sequentially).

> requirement, will not add actually any new requirements.

Having to look up both SRV and A records adds at least (and possibly 
more) one round-trip.  SRV requires the use of non-standard APIs AFAIR 
(e.g., getrrsetbyname), which may or may not be present.

And then there is inter-domain anycast..

> need to move to the 2nd way, or there is an alternative.

A prefix might be possible for some inter-domain services, but for 
those that aren't, IMHO it should be dropped completely.

And even for inter-domain, I don't think there are any which would 
need it: Teredo had it before, but it was removed due to review from 
routing people (because one would need to send packet with the anycast 
address as the source to pierce the NATs), or just as a discovery 
method.  For something like TSP, this wouldn't make sense because you 
could end up with different providers, with different prefixes. 
Again, this would only make marginal sense as 'discovery of the 
unicast address', not much else.

Hence, I'm not so sure that inter-domain anycast address is really 
needed now.