Subject: [v6tc] Issue 2: service discovery: automatic or manual?

From: Alain Durand <[email-masked]>
Date: Tue, 11 Jan 2005 02:43:37 -0800

Hi all, and happy new year!

I'd like to start 2005 discussions with a new thread on service 
discovery.
 From the potential charter I sent last year:

 > Work items:
 > ----------------
 > The problem can be decomposed into two independent areas:
 >	a) Having a way for an ISP to indicate that it is offering tunnel 
services to its direct customers,
 >	    and how to invoke them. This is also known as tunnel end-point 
discovery.
 >	    Due to the large variety of customer configuration expected, 
classic mechanisms
 >	    like DHCP or SLP cannot be used (they would have a hard time to 
work through
 >	    an unmodified NAT).
 >	    This mechanism will be limited to the administrative domain 
controlled by the ISP
 >	    and thus could not be used by customers roaming in other ISPs 
networks.
 >
 >	b) Setting up of a tunnel, maybe with some negotiation about various 
parameters.
 >	     For reasons of efficiency over very high latency networks, 
minimizing the number
 >	     of packet exchanges is important, thus it is possible that some 
parameters
 >	     that would normally be obtained over a subsequent DHCPv6 exchange
 >	     (like IPv6 addresses and/or prefixes) would be optionally 
piggybacked into this
 >	     configuration negotiation.

It is clear that we want to make b) as automatic as possible, i.e. 
without any user intervention.
The reason is that there are many parameters to negotiate and any 
manual intervention
will be cumbersome and error prone and will inevitably result in stale 
entries.

Now, it is not as clear, at least to me, that we need the same for a).

	- This is an instance of the general issue of ISP service discovery 
from the customer
  	   nodes that are potentially behind a NAT box. This problem has not 
been solved yet,
	   maybe because it is too difficult, or because there is not enough 
incentive and
	   manual configuration works just fine. If one look at other 
ISP-offered services,
	   like email, web cache, SIP,... they are all configured manually by 
the users
	   by entering simple names like smtp.myISP.com in the relevant boxes. 
And if this
	   is too complex for the average user, the ISP is offering a CD-rom 
that contains
	   a set-up program that does that for you. In the 3GPP case, many 
things are
	   simply pre-configured and there is no discovery involved.

	- The various solutions that have been explored so far all have fatal 
flaws:
		- PPP/DHCP: does not work over the customer owned NAT
		- Well Known Global Anycast IPv4 address: can leak, requires non 
participating
		  ISPs to actively filter out that address
		- Forward DNS: does not match physical topology; ISP domain name
		  is not re-advertised by the customer owned NAT
		- Reverse DNS: does not work well for RFC1918 addresses.

I know that there is a desire in the v6 community to provide fully 
automatic IPv6 service
that gets activated transparently to the final users, but I'm 
wondering, in the context
we are looking at:

 > Enable ISPs (ISPs are defined as traditional broadband ISP, 3GPP, 
enterprise IT department, ...)
 > who have upgraded their core network to v6 one way or another (using 
native links or tunnels)
 > to offer production v6 service to their customers without upgrading 
all  their access network
 > at once (which can be cumbersome, expensive,...)

if this is a realistic expectation or not...

In other words, could we live with a solution where the user will have 
to manually
input on its v6 host or router an address of the form v6TEP.myISP.com 
in the relevant
form? (provided that would be the ONLY thing to input)

	- Alain.

_______________________________________________
v6tc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/v6tc

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Jan 2005 13:01:29 +0200 (EET)

I was hoping someone else would comment, but as that has not 
happened yet...

On Tue, 11 Jan 2005, Alain Durand wrote:
> 	   manual configuration works just fine.

The two last reasons seem likely.

> If one look at other ISP-offered services,

Yes, while there exist a technical mechanism, SRV records, to do this 
already -- this is probably what SRV was intended for.  It just hasn't 
been used by apps, or maybe the service names have not been 
"standardized" sufficiently, or the ISPs don't bother putting in SRV 
records, or this is deemed too marginal.

> 		- Well Known Global Anycast IPv4 address: can leak, requires non participating

ISP domain name is not advertised, AFAICS, only if the customer 
manually configures his/her own domain name.  Such user is probably 
sufficiently knowledgeable, one we might not need to care about (97% 
instead of 100% solution).

Global anycast address might also be an option, but it might be more 
difficult to set up at ISPs, and the failure mode might be more 
difficult to manage. (If a DNS lookup fails, you get the failure 
immediately, but you have to wait for some kind of reply from the 
anycast address..)

> In other words, could we live with a solution where the user will 
> have to manually input on its v6 host or router an address of the 
> form v6TEP.myISP.com in the relevant form? (provided that would be 
> the ONLY thing to input)

I believe automatically discovering the tunneling capability is the 
most important part about the solution and it would not be good to 
have to leave it out.

However, as you said earlier, this is orthogonal to the 
protocol/set-up procedure itself, so these can be worked in parallel, 
and if nothing comes up from this discovery, one could just decide to 
go for manual configuration instead.

-- 
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: Alain Durand <[email-masked]>
Date: Wed, 12 Jan 2005 05:05:35 -0800

> instead of 100% solution).

I just installed a Apple Airport network. By default, the DHCP server 
advertise internally the DNS domain "lan".
Thus any DNS methods (using SRV or other record types) will look for 
things like _TEP.lan and fail miserably.

	- Alain.

---

From: Alain Durand <[email-masked]>
Date: Wed, 12 Jan 2005 06:35:58 -0800

On Jan 12, 2005, at 3:01 AM, Pekka Savola wrote:
>> 	   like email, web cache, SIP,... they are all configured manually 
>> by the users

Essentially the whole discovery issue is a bootstrapping one:
How do you find the first anchor?

To make my previous point clearer, in order to use SRV records in the 
DNS, you first need to know
what the ISP domain name is. This information is NOT necessarily 
propagated
to the customer nodes, especially in the case where a customer owned  
NAT is present in the picture.

	- Alain.

---

From: "Miguel Angel Diaz" <[email-masked]>
Date: Thu, 13 Jan 2005 10:20:37 +0100

Hi all,

we (Jordi and me) are working in a method to discover the ISP domain name in order to use SRV records. The method is simple and it could work in all the possible scenarios where the user might be.

We need to refine it before to announce it, but in the next days we will hopefully have a draft version to share with all of you and ready to receive comments from all of you.

Regards
Miguel

----- Original Message ----- 
From: "Alain Durand" <[email-masked]>
To: "Pekka Savola" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 12, 2005 3:35 PM
Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual?

> NAT is present in the picture.

**********************************
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: Jeroen Massar <[email-masked]>
Date: Thu, 13 Jan 2005 11:12:52 +0100

On Thu, 2005-01-13 at 10:20 +0100, Miguel Angel Diaz wrote:
> Hi all,
> 
> we (Jordi and me) are working in a method to discover
> the ISP domain name in order to use SRV records.
> The method is simple and it could work in all the possible
> scenarios where the user might be.

Let's take my simple home network:

{ ADSL provider } <-------> { Router } <------> {Hosts}

Router is in this case a Linux box doing IPv4 NAT + IPv6 routing + DNS +
DHCP for Hosts. Everything behind and including my Router has a reverse
of unfix.org. (router=purgatory.unfix.org, hell.unfix.org,
heaven.unfix.org)

My (now former ISP) uses cistron.net for all it's routers, thus a
traceroute would look like:

hell.unfix.org (localhost)
purgatory.unfix.org (router)
blabla-dsl.cistron.net

What is the "ISP domain name" in this scenario?

Also, even though they have an IPv6 allocation, they do not provide it
to their clients for several hardware/software reasons.

So even if you could find out the correct domain name of the ISP, there
would be no SRV records there anyway.

Thus I am really wondering how you will try to make this work 'for all
cases'.

I am still convinced that anycast is the way and that a 'anycast
service' prefix would be the best thing to have.

Greets,
 Jeroen

---

From: Alain Durand <[email-masked]>
Date: Thu, 13 Jan 2005 02:33:06 -0800

> service' prefix would be the best thing to have.

Don't forget that well known global anycast has problems too...

If you are customer of an ISP that does not offer the v6 tunneling 
service,
chances are that it will not filter out that well known address either
and your packets will simply follow the default route and end up
in a random places. Very difficult to debug.

	- Alain.

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 13 Jan 2005 11:44:39 +0100

> in a random places. Very difficult to debug.

What is so difficult about:
traceroute 2001:db8::1 (or 192.0.2.1 or whatever it gets).

And what is so hard to debug about BGP anyway? Isn't this what happens
daily when routing problems occur?
It works for the a number of root DNS servers too.

I made a long proposal once already but that was silently ignored, too
bad as it would solve a *lot* of autoconfiguration, al in one go.

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Jan 2005 13:11:40 +0200 (EET)

> service' prefix would be the best thing to have.

Considering the tradeoffs, this may be a feasible option.

The main differences are in:
  1) detecting if the service does not exist: i.e., how does the tunnel 
negotiation/set-up code detect if there is no service (e.g., the ISP 
might have a Null0 defalt route).  A ping6 might be possible.
(DNS is easier, because if you don't get an address back, you know it 
immediately.)

  2) how to set it up: a DNS (or similar) solution does not require 
setting up the anycast address.  The DNS approach would be slightly 
simpler in some circumstances, e.g., enterprises.

---

From: Alain Durand <[email-masked]>
Date: Thu, 13 Jan 2005 04:25:34 -0800

> daily when routing problems occur?

This is what is used by ISPs, not end user...
If there is a problem with a user trying to get a tunnel
with an ISP not offering the service, it is very hard for that
end user to get effective help.

> It works for the a number of root DNS servers too.

There is a fundamental difference between global anycast
used for some root DNS servers and what we want to do here.

In the case of the root DNS servers, they are all semantically 
equivalent,
i.e. your query can go to any one of them and you'll get the very same 
answer.

Here, this is not the case. The semantic of the anycast address would 
be:
"find the the closest tunnel server within my ISP range. If this leaks 
out of
the ISP, it will go in random places, and you will get different 
services
depending on your luck:
	- you can reach the bit bucket
	- you can reach a tunnel server asking for pre-registration
	  but have no association with it
	- or you can even reach an open relay and things would work

What would be needed actually would be a ISP-locally scoped
well known anycast address and not a globally scoped well known address,
but there is no such thing! And it is not sure at all it would really 
work either,
we know what happened to site local addresses...

The anycast address defined for 6to4 relays falls in the same category 
as
the root DNS server, i.e. it is globally scoped and you can end up 
using any
of the relays and get the same service.

	- Alain.

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 13 Jan 2005 15:06:48 +0100

> end user to get effective help.

"Hi, do you have IPv6", try that with most ISP's, 90% or most likely
more will say say "no" "ehhhh what" or similar stupid answers.

> i.e. your query can go to any one of them and you'll get the very same 

I am quite sure that when I query for the hostname.bind or the hostname
or a "dig +norec @tld1.ultradns.net whoareyou.ultradns.net in a" that I
will get different responses telling me to which node and from who, I am
talking too. BGP is not *that* flaky that you will swap over every n
seconds.

> the ISP, it will go in random places, and you will get different 

You will get the service which is closest by. Isn't this *exactly* what
you where looking for?

> 	- you can reach the bit bucket

Which would do no harm, though it would not work.

> 	  but have no association with it

Which would do no harm, and it will work if you want.

> 	- or you can even reach an open relay and things would work

Which is what we want ;)

> work either, we know what happened to site local addresses...

That is why I say: "Service Prefix", a prefix which can be announced by
ISP's, maybe limited in export by not announcing it globally etc.
This prefix could then have a couple of simple things:

2001:db8::53 / 192.0.2.53 = DNS
2001:db8::25 / 192.0.2.25 = SMTP (outgoing)
2001:db8::110 / 192.0.2.110 = POP3
2001:db8::80 / 192.0.2.80 = HTTP, showing a nice descriptive site of
this service

etc, which would solve all autoconfiguration issues as every box can be
preconfigured with the above. Other approach, could be stuck into DNS:
make a .service domain and let ISP's host that themselves. People can
then use that. Or we could of course go for SLP. But why the heck invent
yet another protocol?

ISP's who do not want such a thing could filter the prefix in BGP, ISP's
who want to announce it to their neighbors could do so. BGP is the
trick. No prefix, then no announcement and you will nicely get a ICMP
network unreachable.

Some 'nice institute', like the RIRs, could announce announce a default
service prefix with only a HTTP service saying "your ISP does not
provide autoconfig" if one really wanted. ISP's not peering with the
RIR's are really sick anyway and ISP's not wanting to give service to
others should not do it.

"I have a problem", then traceroute to 2001:db8::53 and find out where
it leads to.

If you want to be nice to the routing tables you could even reuse one of
the existing anycast prefixes. Now we have one for 6to4, who uses that?
But we want one for proto-x and proto-z and they all have the same
target: providing nearest service.

> as the root DNS server, i.e. it is globally scoped and you can end up 
> using any of the relays and get the same service.

Which is the good thing of 6to4 as you want _service_. If you wanted
quality service you would get native IPv6 or you would get yourself
signed up at a better service.

Greets,
 Jeroen

---

From: Alain Durand <[email-masked]>
Date: Thu, 13 Jan 2005 06:34:45 -0800

> talking too. BGP is not *that* flaky that you will swap over every n

So? What does you example shows? That one can configure specific DNS 
servers
to return specific information depending on who is querying them? So?

All the anycast root servers that you contact to know who
.com is today return a semantically equivalent information.
The point being that global anycast addresses for global service work,
but we cannot extrapolate that global anycast addresses
would work for ISP-scoped services.

> You will get the service which is closest by. Isn't this *exactly* what

No. I want to go the the closest tunnel server of _my_ ISP.
Not any tunnel server from any random ISP.
And if my ISP does not offer the service, I want to know it asap.

> 2001:db8::80 / 192.0.2.80 = HTTP, showing a nice descriptive site of

Ok, so you invent those ISP-scoped anycast addresses.

Now I have a PC connected to two ISPs. What do I do?
As I cannot tell from the address on which interface to send it too,
I need to re-introduce all the complexity in the code
that we hoped to avoid when we deprecated site local addresses...
I need to remember, this is a 'special' address, I should not look-up
my normal routing table, but 'remember' it is associated with
a specific ISP, and this with a specific outgoing interface...
Now makes the scenario a bit more complex, and introduce
the multi-ISP router, and you have a interesting problem...

> make a .service domain

That could technically work, with the same objections as the ones 
described above.
However, looking at the controversy over the .local domain,
I doubt it would be quickly adopted...

> and let ISP's host that themselves. People can
> ISP's who do not want such a thing could filter the prefix in BGP

This is exactly where I see a problem...
The question is for ISP who do not care at all, i.e., who do
not run the service internally and do not filter out the prefix.
Then random, unpredictable things may happen.

> , ISP's

How can you guaranty that no one else is injecting the same prefix?

	- Alain.

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 13 Jan 2005 16:30:48 +0100

> would work for ISP-scoped services.

Any reasons why this would not be the case?
Have you experimented with this or are there known problems?

> And if my ISP does not offer the service, I want to know it asap.

Then the draft for such a service prefix should include:
 - Do not redistribute this prefix globally.

Pronto presto done.

> Now I have a PC connected to two ISPs. What do I do?

How does normal multihoming work, at least assuming that you are talking
about L3/IP-layer multihoming and not about L2 multihoming.

> a specific ISP, and this with a specific outgoing interface...

What is the difference with configuring your multihomed router? If you
are in the first place able to do so, then I really see no issue.
And more likely, if you have such an advanced network that you are
multihomed you are quite easily able to set this up to.

> the multi-ISP router, and you have a interesting problem...

I do not know a single organisation that is multihomed with different
source IP's. In the cases they are multihomed on L3, they simply tend to
have multiple upstreams. The person/organization who configured this is
most likely quite capable of configuring the service prefix too in too
cases. Any further issues?

Or to put the question differently: how is this different from the
proposal of looking it up from DNS SRV records?
I think routing is easier to fix in those cases ;)

> Then random, unpredictable things may happen.

Thus like I mentioned above "thou shalt not announce the service prefix
globally".

> How can you guaranty that no one else is injecting the same prefix?

If you do not trust your peers then you should not be peering with them.
There are many methods of filtering, if you do not know them you should
not be in the ISP business.

Greets,
 Jeroen

---

From: Alain Durand <[email-masked]>
Date: Fri, 14 Jan 2005 05:45:13 -0800

Well, the discussion on this topic has a bit rat-holing into anycast 
deployment issues,

> form? (provided that would be the ONLY thing to input)

... or do we absolutely require an automatic discovery mechanism?

I would like to invite those who haven't expressed themselves on
this very point to participate in the debate.

	- Alain.

---

From: "Miguel Angel Diaz" <[email-masked]>
Date: Fri, 14 Jan 2005 19:49:48 +0100

Even in your case the discovery method we are going to propose will work. Basically we only suppose one thing: the local ISP is the entity that deploys the TEP that the user (rather the OS) is looking for.

With that premise we propose to use SRV RR because the advantages shown in http://www.ietf.org/internet-drafts/draft-palet-v6ops-solution-tun-auto-disc-01.txt. However to use effectively that approach it is necessary to know the ISP domain name which is not trivial because it is not usually propagated.

The new draft version of draft-palet-v6ops-solution-tun-auto-disc will propose a method to discover not only the ISP domain name but also the DNS server to make the SRV queries. To do that the only thing is to find out the authoritative DNS server on the ISP domain and then you'll have all.

In this way the queries will be sent not to your local DNS server but the authoritative DNS server of your ISP who is in charge of the TEP deployment, so it will work even in your network.

More information soon....

Regards
Miguel

---

From: "Miguel Angel Diaz" <[email-masked]>
Date: Fri, 14 Jan 2005 19:50:09 +0100

> ... or do we absolutely require an automatic discovery mechanism?

IMHO if we wish a broad and fast deployment of IPv6 the answer is that an automatic discovery mechanism is definitively required. 

Today many ISPs are wondering why should they deploy IPv6 in their core networks or in their access networks if no IPv6 traffic is detected.

On the other hand, hardware manufacturers, application developers and users in general are wondering why should they need IPv6 in the products that they develop/use if users don't have IPv6 connectivity either native or by mean of an easy/automatic transition mechanism.

In these circumstances, ISP will never detect IPv6 traffic because users (normal users) don't know (and likely don't want to) how to find TEPs and how to configure IPv6 tunnels, and product developers aren't pushed neither to develop IPv6 products/application (which would generate the IPv6 traffic) because they depend on the technical knowledge of users (usually minimal if any).

This is a bootstrapping and the only way to solve it is by easing the IPv6 transition. One efficient mean is an auto-discovery mechanism that finds the TEP by itself and users don't have to be worried about it.

Let's think that there could be a lot of IPv6 devices like cameras, home automation devices, cars, etc that could take advantage of an automatic discovery method to find IPv6 connectivity without human intervention.

So, IMHO the answer is that we can't live with methods that require users to enter any URL or data.

Regards
Miguel

---

From: Florent Parent <[email-masked]>
Date: Sun, 16 Jan 2005 22:30:45 -0500

> this very point to participate in the debate.

Automatic discovery should be focused within an "autonomous system" 
(enterprise/ISP/etc.). For example, if anycast is used, such address should 
be confined to the autonomous system routing system. How it's done 
(anycast, DNS, etc.) is left to be defined.

I think automatic discovery should be done in order to cover the zero-conf. 
tunneling goals.

In the roaming scenario (or getting service across an IPv4 only ISP), some 
manually configured parameter would be required from the user (e.g. tunnel 
service FQDN of your IPv6 provider). This manual configuration isn't alien 
to users and is done in many client software.

Florent

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 17 Jan 2005 16:56:03 +0100

On Fri, 2005-01-14 at 19:50 +0100, Miguel Angel Diaz wrote:
> IMHO if we wish a broad and fast deployment of IPv6 the answer is that an
> automatic discovery mechanism is definitively required. 

There is already Teredo and 6to4, what more is needed?
Teredo on it's own already solves most if not all problems.
The only issue with Teredo _could_ be that one does not get the most
local relay. But I think M$ can be easily pursuade to add a update to
windowsupdate that will reconfigure the default teredoserver to an
anycast address.

The point more is: who uses it?

> Today many ISPs are wondering why should they deploy IPv6 in their core networks
> or in their access networks if no IPv6 traffic is detected.

How can they claim they don't see traffic if they don't have any
connectivity. This is really a weird and invalid assumption.
The thing has to do with one simple thing: Money.
And IPv6 as connectivity does not get them extra cash in their pockets
why would they even bother with it?

Tell them that they can generate revenue and how and they will focus on
it. But getting a re-schooling for their, most likely already, under-
educated helpdesk and the many other parts of their organization is
really not where they are going to invest money into.
As the moment the provide it they also need to provide support.

"Hi this is Grandma, my internet does not work"

> On the other hand, hardware manufacturers, application developers and users in
> general are wondering why should they need IPv6 in the products that
> they develop/use if users don't have IPv6 connectivity either native
> or by mean of an easy/automatic transition mechanism.

Users don't know what IP is, what version it is, they don't care nor do
they want to care.

To put it bluntly: they want ass, tits and a lot of killing in their
virtual warfields.

Does Doom3 support IPv6? Does Halo2 support IPv6? Does Half Life support
it? => No. Should somebody as a being a normal user care? No?
Does their porn work over IPv4? => Yes, so do they care for IPv6? => No.

There is this nice blonde girl singing a nice song: It is all about the
money. And even though in the US the DoD claim to invest billions for
IPv6, there is no such thing toward the enduser. Thus should the
provider for endusers care? => No.

> In these circumstances, ISP will never detect IPv6 traffic because users (normal
> users) don't know (and likely don't want to) how to find TEPs and how to configure
> IPv6 tunnels

They apparently know very well how to do all this. Google for newsserver
and IPv6 and free and similar wordings. Tutorials are there for the grab
and then you don't even see the backroom chats where the trading is
going on.

> , and product developers aren't pushed neither to develop IPv6
> products/application (which would generate the IPv6 traffic) because they depend
> on the technical knowledge of users (usually minimal if any).

Product developers don't see money in IPv6 so why would they care?

> This is a bootstrapping and the only way to solve it is by easing the IPv6 transition.
> One efficient mean is an auto-discovery mechanism that finds the TEP by itself and users don't have to be worried about it.

Ever considered Teredo ?

> Let's think that there could be a lot of IPv6 devices like cameras, home automation devices, cars, etc that
> could take advantage of an automatic discovery method to find IPv6 connectivity without human intervention.

Now if I would live in Tokio I could live with this assumption, but
unfortunately, unless I go to Akibara myself or import the stuff I will
not be able to buy these cool toys (yet).

Also, the router in the house should provide this, not the camera, that
should simply RA. Next to that does the word 'security' say anything?

> So, IMHO the answer is that we can't live with methods that require users to enter any URL or data.

I know of almost 3500 happy users who lived with this perfectly fine and
there are a number of other organizations who claim to have way more
users.

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 17 Jan 2005 17:06:10 +0100

On Fri, 2005-01-14 at 19:49 +0100, Miguel Angel Diaz wrote:
> Even in your case the discovery method we are going to propose will work.

Can you please explain me how it would work? Because I really can't see
how it can because there is absolutely no information that makes you
able to figure out the nameservers of the ISP with the information I
gave below ;)

>  Basically we only suppose one thing: the local ISP is the entity that deploys the TEP that the user (rather the OS) is looking for.
>
> With that premise we propose to use SRV RR because the advantages shown
> in http://www.ietf.org/internet-drafts/draft-palet-v6ops-solution-tun-auto-disc-01.txt.
> However to use effectively that approach it is necessary to know the ISP domain
> name which is not trivial because it is not usually propagated.

That was the question I asked you, how are you going to figure out in
which domain you need to look for those records?

> The new draft version of draft-palet-v6ops-solution-tun-auto-disc will propose a
> method to discover not only the ISP domain name but also the DNS server to make the SRV queries.

You think that my DNS server has a relation to the DNS server of my
upstream ISP? No way, they don't do IPv6 nor DNSSEC and mine does.

> To do that the only thing is to find out the authoritative DNS server on the ISP domain and then you'll have all.

And _how_ are you going to do it? that you want to do it is clear, but
how? :)

> In this way the queries will be sent not to your local DNS server but the
> authoritative DNS server of your ISP who is in charge of the TEP deployment, so it will work even in your network.

Please look again at the situation that I depicted as there really is no
way to find out the domain name of my upstream ISP :)
It is not even possible to do it manually unless you simply assume
certain things, but that is done by the human brain, not by the
computer.

Greets,
 Jeroen

---

From: Tim Chown <[email-masked]>
Date: Mon, 17 Jan 2005 16:07:31 +0000

> IMHO if we wish a broad and fast deployment of IPv6 the answer is that an automatic discovery mechanism is definitively required. 

I do tend to agree, despite the hurdles that this poses.  

The sort of scenario Jeroen paints is one where the local user/admin has
a specific customisation beyond where the typical Joe Boradband user would
be, so I think that sort of power user could manually configure their IPv6
connectivity.

> So, IMHO the answer is that we can't live with methods that require users to enter any URL or data.

Well, at home I still have trouble finding what SMTP server to use for my
ADSL service.   Luckily I use a remote service via ssh so I don't need to
know, but the problem exists for other settings, as has been pointed out here
already.

Tim

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 17 Jan 2005 18:29:25 +0100

> be, so I think that sort of power user could manually configure their IPv6

Fortunately you see my point, but I do have to note that you should not
underestimate Joe Broadband user and his/her need for the newest
movies/music and other goodies which will let the RIAA turn over in
their graves even before they go into it. Pick up Joe Broadband's PC
magazine and check which nice tutorials are in there in you will get
what I mean, they are usually to low-tech but otherwise they could point
quite interesting even for people who are in the industry.

But even if I did not customize that much. Finding the DNS name of "my
ISP" would already be undoable in the following very standard situation:

+-------+        +---------+
|  ISP  |--------| NAT Box |-------{ hosts }
+-------+        +---------+

If I would configure my home network like this, then still there is no
way to figure out that my ISP actually uses cistron.nl and not .net as
in the traceroutes or as the reverse of services etc. SOA's are pointing
to .net, reverses are .net, but the services reside in the .nl domain.
And I am not even mentioning the various Virtual ISP's who actually
outsource everything. That is why I wonder how Miguel et al are going to
use these nice DNS SRV records ;)

Also assuming that you can figure it out, if there is no DNS SRV record
in the upstream, what then? No service for that user? There is nothing
automatic in this setup then as there are almost no ISP's doing IPv6 in
the first place, that is why there is 6to4 and Teredo, who fit the bill
perfectly as I already mentioned.

> know, but the problem exists for other settings, as has been pointed out here

Which can be solved easily as I mentioned before: Service Prefix.
2001:db8::25 = smtp. No configuration no nothing.

Or do it wpad (http://www.wlug.org.nz/WPAD) style. Aka have a common
known url where the configuration settings can be fetched.
Thus http://2001:db8::4170/autoconfiguration/
and tada your sweet little computer will receive:
SMTP: smtp.example.net
POP3: pop3.outsourced.example.com
TEP: miguels.uber.tep.example.net

etc.... whatever you want. Oh and please, don't forget SLP (RFC2608).

Don't think about failover to much, if your upstream ISP is dead then
you can't reach it either. Just like when they don't fix such services
you can't use them, simple. If you want resilience: pay for it.
Like Meja says: It's all about the money ;)

Greets,
 Jeroen

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 22 Jan 2005 23:24:40 +0100

I guess that here we clearly disagree ...

I think the purpose of this work, at least when we started it, was
discovering the TEP in any circumstance, not just within the AS.

Otherwise, we may not need it, just say the user when register to the ISP:
"install this software and it comes with the correct setup already".

And just to clarify, for me a TEP is the tunnel end point of ANY transition
mechanism which uses tunneling (whatever encapsulation is being used, as UDP
is for me only the last resort if for example 6in4 can be used). I mean,
doesn't restrict it to a TB.

Regards,
Jordi

> De: Florent Parent <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Sun, 16 Jan 2005 22:30:45 -0500
> Para: <[email-masked]>
> Asunto: Re: refocusing: Re: [v6tc] Issue 2: service discovery: automatic or
> manual?
> 
> 
>

---

From: Alain Durand <[email-masked]>
Date: Mon, 24 Jan 2005 02:25:09 -0800

> discovering the TEP in any circumstance, not just within the AS.

I think we have to agree we disagree here.

> "install this software and it comes with the correct setup already".

This is the question I have been asking. Why is this not enough?

> doesn't restrict it to a TB.

By focusing on TB, we have a good chance of success. Focusing
on finding any TEP in the Internet for any transition mechanism
is a much larger problem, much harder, and the chances of success
do not look very good to me.

	- Alain.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 24 Jan 2005 06:27:37 -0500

Hi,

My reply below, in-line.

Regards,
Jordi

> De: Alain Durand <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Mon, 24 Jan 2005 02:25:09 -0800
> Para: <[email-masked]>
> CC: <[email-masked]>

Because this will only work if the service is only available from your ISP
... but doesn't work when you want to discover for example free TBs or other
free transition mechanisms.

> do not look very good to me.

I don't agree here, it may see a much larger problem but looking into the
proposed solutions (that's why we did a so exhaustive and long analysis
document !), the problem is only 1% more harder (versus only TB). The way we
described the solution, even if we (for example), finally decide to go only
for anycast, it works transparently for all the transition mechanism, even
w/o the need to modify them. Instead the OS look for the right TEP and
parses what has been discovered using anycast to the mechanism.

Of course, it depends on the final solution, for example if we go for
anycast, the simpler way to make it olnly a 1% more harder problem is to
have one anycast prefix for every transition mechanism.

So my point of view is that we don't need to close this decision right now,
until we move on to fix the possible solutions (may be there are others
better than our, but which only solve the problem for TB and those solutions
are much harder, as you say, to cover the "any" transition TEP).

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 24 Jan 2005 14:08:09 +0100

> This is the question I have been asking. Why is this not enough?

Also this is extremely easy to deploy (couple of binaries on the website
and let them click). It works always* in every scenario, unless some
stupid firewall blocks some protocol or port of course. But with UDP
this should be quite safe in most situations and where it is not you
can't get out of there easily anyway and the IETF should not be trying
to circumvent administrative barriers. I can already hear the admins
screaming "Hey they opened my network wide open"...

* I have to note that it is a lot of fun making a tool which actually
can configure routing etc automatically, especially when the user has
been either playing around with the ipv6 settings before without knowing
what was being done, it was done automatically or that this person
preconfigured it with knowledge and wants to keep it. That said, one can
define a number of great protocols and have long discussions about this,
but if nobody (wants to) make an implementation one is dead in the water
anyway...

> do not look very good to me.

One could have an anycast prefix announcing where to find the closest
TB. But as mentioned this would then have that TB announce itself and
will involve some kind of business advantages/disadvantages, though I
can't see any competition in this kind of business, at least at the
moment, even though this is the IETF, this will be weighed in by several
people.

As I have mentioned before quite a number of times there are already a
number of openly deployed solutions for these problems. Probably the
best one is TSP, being included in most linux distributions and like
mentioned above downloadable from some places, preconfigured to do what
they want. And also takes care of the number of requirements mentioned
in the various threads which came up. For that matter, what is the use
of defining this all again, while it is being used already? Why not try
to define the bottlenecks and deficiencies in the tools that are out
there and try to fix those? Having a list of these is good anyway
because that can, and no the large solution/analysis documents don't
make sense and they don't even cover them correctly. Fun to see a lot of
letters, but they don't contain anything useful IMHO.

> JORDI PALET MARTINEZ wrote:
> > Alain Durand <[email-masked]>

What is bad with that? You *pay* your ISP and thus demand them to give you service.

> free transition mechanisms.

I would not want to use a free anything if I am paying my ISP who should be doing it.
Next to that DNS would fail completely in this case as there is no way to discover
a 'free' something because it is unrelated to any form of DNS you can think of.
Anycast could work, getting you the closest one, but does one really want to use them?

The download and be done with it method works perfectly fine here. People who currently
don't know what IPv6 is, use Teredo or 6to4 automatically, people who want a choice can use
the various tools which are available already, for free in most cases.

> the problem is only 1% more harder (versus only TB).

I wonder how you can express something undefined in percentages, even expressing defined
things in percentages is silly, this is protocol work, not banking ;)

> The way we

What does this gain over the currently deployed solutions?
Next to that the OS doesn't do a thing, a tool in the distribution might.
Did I mention 'dig @192.0.2.53 ipv6.tep.service txt' ? ;)

> have one anycast prefix for every transition mechanism.

Where does this 1% come from? And how is *the* solution going to pick *the*
perfect transition mechanism? What if the position of the moon changes?

> are much harder, as you say, to cover the "any" transition TEP).

Did someone present a (possibly) working solution already? The exact requirements
have not even been formulated yet.

Greets,
 Jeroen