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

[Alain Durand <[e-mail]>]

On Jan 13, 2005, at 6:06 AM, Jeroen Massar wrote:
>> 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.
>
> 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.

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.

>> the ISP, it will go in random places, and you will get different
>> services
>
> You will get the service which is closest by. Isn't this *exactly* what
> you where looking for?

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.

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

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


> 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

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

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

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

	- Alain.


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