Subject: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automaticor manual?

From: "Miguel Angel Diaz" <[email-masked]>
Date: Wed, 19 Jan 2005 09:53:18 +0100

> On Tue, 2005-01-18 at 05:52 -0800, Alain Durand wrote:
>> On Jan 18, 2005, at 4:25 AM, Pekka Savola wrote:
>> > What seems left on the table from the generic solutions is an IPv4 
>> > anycast address.  It has some problems, but maybe these problems are 
>> > smaller than with others.
>> 
>> I think the discussion from the last few days has shown few things:
>> 
>> a) DNS based solutions (forward or reverse) do not work in all 
>> situations and in particular do not work well in the case where a NAT box is 
>> present, which seems to be a show stopper.

I disagree partially with that assertion because by using reverse+forward DNS with either the public IP of the customer or the customer's default gateway would work in the most cases. Only two conditions are needed:

- ISP configures properly the reverse DNS
- ISP configures properly the DNS server to be included on the reverse domain the names for the discovery services.

Whit this assumptions even with local DNS server on the customer network, the discovery based on DNS will work.

How to find out the public IP is not so hard as it has pointed before. STUN is only an alternative, but there is other ones even much better.

Regards
Miguel

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

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

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 19 Jan 2005 10:01:11 +0100

On Wed, 2005-01-19 at 09:53 +0100, Miguel Angel Diaz wrote:
> I disagree partially with that assertion because by using reverse+forward DNS
> with either the public IP of the customer or the customer's default gateway
> would work in the most cases. Only two conditions are needed:
> 

ISP's should also configure ingress filtering, should also provide
native IPv6, should not have open mail relays.... many other things that
will not happen. Don't assume that they will magically appear for this
all of a sudden.

> Whit this assumptions even with local DNS server on the customer network, the discovery based on DNS will work.

With these assumptions it will work in only a few cases and not for most
cases and thus it is completely useless for most people. The target was
most people, not only a few.

> How to find out the public IP is not so hard as it has pointed before.
> STUN is only an alternative, but there is other ones even much better.

And the 'better ones' are? Using http://www.whatismyip.com/ ? :)

Greets,
 Jeroen

---

From: "Miguel Angel Diaz" <[email-masked]>
Date: Wed, 19 Jan 2005 10:05:17 +0100

[......................................]

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

Regards
Miguel

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Wed, 19 Jan 2005 12:53:25 +0200

Miguel,

> How to find out the public IP is not so hard as it has pointed before. STUN is only an alternative, but there is other ones even much better.

I think there has been now some discussion on this. The problem with
your proposal really is that expect something to happen, which boils
down to the same problems as the original problem: Finding the server
that can give you your the public IP address.

In addition, your solutions sadly need a certain kind of network
deployment that might or might not be true always. Expecting that the
ISP has deployed the network in a certain special way or even worse
assuming something from the user's home network leads to broken
assumptions.

Cheers,

Jonne.
> ______________________________________________________________________
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]