Subject: RE: endpoint discovery from reverse DNS [Re: other comments on dr aft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Mon, 8 Nov 2004 14:36:01 +0100

> That said, the approach seems to be fairly good when you're only 
> considering one administrative domain, and the tunnel point deployed 
> in that administrative domain.  But isn't that scenario equally 
> addressed with a DHCP option, using a more operator-friendly approach?
> 

Dhcp isn't supported in all cases, dns is.

Karen
> -- 
> 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: Radhakrishnan Suryanarayanan <[email-masked]>
Date: Mon, 08 Nov 2004 19:17:37 +0530

> Dhcp isn't supported in all cases, dns is.
I too agree with this point. :)

---

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Nov 2004 16:30:17 +0200 (EET)

> Dhcp isn't supported in all cases, dns is.

Agreed for 3GPP.  Not sure if I see other major scenarios. (All the 
ISP cases are all in the different administrative domain.)

But how many of these cases are such that a DNS search-path based 
approach would not be suitable (due to the requirement to have more 
control on which tunnel endpoints each are selected by which node, as 
pointed out by Alain)?

---

From: Alain Durand <[email-masked]>
Date: Mon, 08 Nov 2004 08:20:08 -0800

> control on which tunnel endpoints each are selected by which node, as 

Any large network that spans different locations and uses potentially 
multiple domains.
This is true for large enterprise networks, but also at home if the user 
decided to have its
own local domain advertized through DHCP. For example, at home, my local 
DHCP
server is configured to send a search path as "sun.com" and 
"mylocaldomain.example.com",
but not "myISP.example.com"

So if i was to use the DNS search path in the forward tree, I would 
end-up looking for
Tunnel-end-point.sun.com or Tunnel-end-point.mylocaldomain.example.com 
but never
for the right thing, that is Tunnel-end-point.myISP.example.com.

To paraphase what Rob Austien once said about automatic completion using 
domain search list,
when you do not know what the question you ask is, don't be surprised if 
you don't find the answer.

In other words, you should never believe that is advertized as your 
domain name
is relevant to figure out where you are physically on the network.

    - Alain.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 9 Nov 2004 21:20:15 +0200 (EET)

On Mon, 8 Nov 2004, Alain Durand wrote:
>> But how many of these cases are such that a DNS search-path based approach 
>> would not be suitable (due to the requirement to have more control on which 
>> tunnel endpoints each are selected by which node, as pointed out by Alain)?
>
> Any large network that spans different locations and uses 
> potentially multiple domains. This is true for large enterprise 
> networks, but also at home if the user decided to have its own local 
> domain advertized through DHCP. For example, at home, my local DHCP 
> "mylocaldomain.example.com", but not "myISP.example.com"

I do not see this as a problem one way or the other.  If the user is 
knowledgeable to configure his/her is own DNS zone (w/ DNS server 
etc.), he's likely knowledgeable to manually configure the discovery 
process to look for protocol.myisp.com instead.

More likely than not, most if not all of those users already have v6 
acces ;-)

On the other hand, please remember that reverse DNS based 
configuration will likely need similar manual configuration as well.

> To paraphase what Rob Austien once said about automatic completion 
> using domain search list, when you do not know what the question you 
> ask is, don't be surprised if you don't find the answer.

Certainly.  The mechanism doesn't need to be perfect, especially for 
power users; it just needs to be good enough, and robust enough 
especially for those who are not sufficiently technically 
knowledgeable to do custom configuration.

> domain name is relevant to figure out where you are physically on 
> the network.

Disagree.  By default it would appear to be relevant, but there are 
cases (especially when there has been manual configuration by a 
knowledgeable user) where this does not hold.  I've the assumption 
that we may not need to be all that worried about those particular 
scenarios.

But this kind of assumption needs to be spelled out.