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

[aggregating mails and please fix your mailer as you are misquoting
people and that becomes a huge mess]

On Wed, 2005-01-19 at 09:30 +0100, Miguel Angel Diaz wrote:
> > On Tue, 2005-01-18 at 04:21 -0800, Alain Durand wrote:
> >> On Jan 18, 2005, at 3:37 AM, Miguel Angel Diaz wrote:
<SNIP>
> >> > stun01.sipphone.com,
> >> > stun.voxgratia.org,
> >> > stun1.vovida.org,
> >> > stun.fwdnet.net,
> >> > stun.intervivo.net
> >> >
> >> > Why don't use them?
> >> 
> >> Simply because hardcoding names like that in implementations that need 
> >> to be
> >> maintained for 10-20 years is a bad thing.

<this section was for instance written by me>

> > Not even mentioning the abuse of resources provided by others.
> > 
> > And what is the use of using a STUN in the first place, if it cannot be
> > reached you are dead in the water.
> 
> With pings or traceroutes the STUN protocol could be avoided. Even better,
> trying to reverse the IP of the ISP gateway (first hop from the customer's network)
> would be a nice solution to discover the ISP's domain name.

I can't even traceroute from most places because ICMP is blocked.
And who says that the first hop from the current IP is the ISP's
network? You might want to try full automated whois queries and how much
intelligence are you wanting to put into it ?

On Wed, 2005-01-19 at 09:30 +0100, Miguel Angel Diaz wrote: 
> > On Tue, 2005-01-18 at 03:18 -0800, Alain Durand wrote:
> >> On Jan 18, 2005, at 2:39 AM, Miguel Angel Diaz wrote:
> >> >> On Jan 18, 2005, at 1:17 AM, Miguel Angel Diaz wrote:
<SNIP>
< this section was actually from me....>
> > That is why I offered him the traceroute option, to at least get the
> > IP's and then the reverses of the ISP, not that it would be really
> > visible and quite hard to find out then where a) to trace to and b)
> > which hop actually belongs to the ISP, but still ;)
> > 
> 
> With traceroute it would be even better to discover the IP, at least and some scnerios

In *some* but not *all* or even *most*.

> > Also miguel, you really think that I did not have a special reverse on
> > my box? At least internally 195.64.92.136 is also nicely known as
> > purgatory.unfix.org and thus the SOA is also inside unfix.org, the NS
> > records are at purgatory.unfix.org and ns1/ns2.mediadesign.nl. Does this
> > lead you to cistron.nl?
> 
> So that's one case where tracertoue might be more usefull because it would be
> used the IP of your ISP default gateway rather than your ouwn public IP

As mentioned before which of the zillion options are you going to try and how
sure are you that the option you pick is the best?

And as my network actually consists out of:

[laptop with XP] <---> [wireless router] <--> [dsl] <--> [dslam] <--> [ix/transit]

You would fail _again_.

Oh and this is a common, not even "power user" scenario used by many
with PPTP or PPPOE DSL connections.

> > 
> > I also have to note that:
> > - many ISP's don't do reverse at all
> 
> The most of IP tests we've made shown the oposite. I guess that the most
> of ISP do it. Anyway, with discovery based on DNS, ISP will be adviced that reverse is a must.

"most IP tests", in which region? How much percentage of the IP space did you 'test'?

Reverse has been a "MUST", just like ingress filtering for over more than a decade, but is it there yet?

> > - the ISP's that usually do not use the same domain name as they
> >   use for their services.
> 
> Again, ISP will be adviced that the domain used for discovering should
> be the same that the one usen on reverse

You can write a document, but that does not mean people adhere to it.

> > - custom reverses exist too.
> 
> So, trying reverse with the first hop of the customer's network, that is the ISP gateway
> will solve it.

And again, how do you know what is the first hop or not? You do not know
this. You can guess and in some cases you might be right but in most you
will not. Also, ever heared of ICMP/UDP filtering? Then you will not be
able to traceroute at all.

And from a third mail:

> Miguel Angel Diaz wrote:
> > Alain Durand wrote:
> > c) Anycast based solution are workable in theory but there are 
> > operational concerns.
> > More feedback from the ISP community and the rest of the IETF is 
> > necessary. It may be the case that this should be the focus of a dedicated wg.
> > 
> 
> Even althouth anycast based solution is workable in theory, one only anycast prefix
> to be used by all the kind of TEPs (6to4, teredo, ayiya, etc.) will require a handshake
> to know/inform the required TEP, which forces ISPs to waste more resources on the deployment.
> Same for implementors.

Very easy solution that is <1 hour work for most implementors:

Setup a DNS server on 2001:db8::53 or 192.0.2.53.
This DNS server has a DNS zone: .service containing eg:

_teredo._udp.service. CNAME teredo.example.com.
_6to4._proto41.service. A 192.88.99.1

Works over UDP, no 'handshakes' nothing... Now what was the problem again?

And if the client wants to know what possibilities there are it could
simply AXFR the .service zone, tada.

Funny that you are actually worried about handshakes, while you are
trying to involve: traceroutes (icmp/udp) + reverse DNS and a hell lot
of other false assumptions.

From rom a fourth mail:
> Miguel Angel Diaz wrote:
> > Alain Durand wrote:
> > Simply because hardcoding names like that in implementations that
> > need to be
> > maintained for 10-20 years is a bad thing.
> > 
> 
> So the approach that Jeroen mentioned about using traceroute
> or ping would be an alternative. Furthermore, by using the IP
> of the customer's default gateway would be even better because
> it prevent the reverse done by some customers.

I said that it is *NOT* an alternative. I actually said that was one
of the silly things you would probably opt for next ;)

You cannot read the 'default customer gateway' as there is quite
likely no way to even look into the router at all.
Or are you expecting that suddenly everybody builds in some magic there?
The magic would then be building IPv6 in the router, not anything else.

Greets,
 Jeroen

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

Attachment: signature.asc