[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt
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 <pekkas@netcore.fi>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Mon, 18 Oct 2004 09:41:13 +0300 (EEST)
> Para: v6ops@ops.ietf.org
> Asunto: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt
>
> 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 ;-),
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.
> 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).
>
> 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.
>
> (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.
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 !
>
> 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.
We can further clarify it in the document probably (working on a new version
right now).
> 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 ;-)
>
> Heck, it might even make sense to put some text, or at least referral to
> section 7, in the introduction.
Ok. Will do it.
>
>
> 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).
>
> 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?
Yes, we discovered already after sending the draft, that was a mistake
forgetting the protocol sequence.
>
> 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.
>
> 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..?
>
Actually this belongs to the complete section 3.
> 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 ?
> 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 ;-)
>
>
> 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).
> 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/ ?
Ok.
>
> 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/ ?
Right.
>
> The solution consequently, makes use of existing protocols, not
> requiring modifications or any new protocol.
>
> ==> remove ','.
Ok.
>
> 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 ?
Right.
>
> the ISP DNS server. To discover the specific TEP within the ISPb@Ys
>
> ==> some corrupted chars around 'ISP'.
Ok.
>
> 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..
Will reword.
>
> This section list de transition mechanisms and the service names to
>
> ==> s/list de/lists the/ ?
Some Spanglish went there by mistake ;-)
Should be "list 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
>
>
>
**********************************
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.