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

[JORDI PALET MARTINEZ <jordi.palet@consulintel.es>]

Hi Pekka,

My comment in-line below.

Regards,
Jordi


> De: Pekka Savola <pekkas@netcore.fi>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Fri, 22 Oct 2004 09:48:42 +0300 (EEST)
> Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
> CC: v6ops@ops.ietf.org
> Asunto: Re: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt
> 
> in-line,
> 
> On Thu, 21 Oct 2004, JORDI PALET MARTINEZ wrote:
>>> 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 ;-),
>> 
>> 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.
> 
> 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.)

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

> 
> 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]

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).

> 
> 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.

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

> 
>>> and 2)  the draft doesn't sufficiently describe the
>>> mechanism/protocol/implementation requirements, and how those
>>> 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).
> 
> 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.

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

> 
>>> 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 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.
> 
> 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.

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.

> 
> 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.
> 
>>> 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.
>> 
>> 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 !
> 
> 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.

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 !

> 
>>> 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).
>> 
>> 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.
> 
> 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.

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

> 
>>> 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.
>> 
>> We wanted to avoid duplicating text from the requirements document ;-)
> 
> 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 ...

> 
>>> 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.
>> 
>> 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).
> 
> 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.

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.

> 
>>> 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? :-)
>> 
>> 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.
> 
> 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.
> 
>>>  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.
>> 
>> We are not referring to the IP address, but to the search path, as you say,
>> so ?
> 
> 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.
> 

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

>>> 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'.
>> 
>> 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.

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 ?

> 
>>> 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'.
>> 
>> IPv4 hops if looking for an IPv4 TEP (to gain access to IPv6).
> 
> Yes, so s/hops/IP hops/

Ok.

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



**********************************
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.