Subject: RE: proposal for a compromise on DNS discovery

From: Syam Madanapalli <[email-masked]>
Date: Wed, 16 Jul 2003 02:07:33 -0700 (PDT)

I think the following approach probably will yield a
better method for DNS Discovery.

As DHCP may not be available in all netwokrs
especially in small networks like Home Networks,
the nodes first should try to get the DNS Resolver
addresses from the RA messages, which will be inline
with the IPv6 Autoconfiguration. If RA messages does
not contain this information, and if DHCPv6 is availbe

the nodes can use DHCPv6 to get the DNS Resolver
Addresses. In case DHCP is also not available, Well
Known Local/Anycast Addresses can be used as Default
DNS Resolvers. Hovewer the draft 
'draft-ietf-ipv6-dns-discovery-xx.txt' 
defines Well Known Site Local Addreses may need to be 
modified as site local addresses are being deprecated.

Thank you,
Syam

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Jul 2003 16:36:01 -0400

>>>>> "Syam" == Syam Madanapalli <[email-masked]> writes:
    Syam> I think the following approach probably will yield a
    Syam> better method for DNS Discovery.

    Syam> As DHCP may not be available in all netwokrs
    Syam> especially in small networks like Home Networks,

  But, a DNS server will be?

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Daniel Senie <[email-masked]>
Date: Fri, 25 Jul 2003 22:50:07 -0400

>   But, a DNS server will be?

Reality check: home networks are, if connected to the Internet, attached 
via a gatewaying device. The de vice of choice for a large number of 
networks is a $60 router from on of any number of vendors. These boxes 
provide DHCP, DNS forwarding and NAT. Perhaps some other environment would 
provide a better strawman? DHCP is pretty prevalent in home networks.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 26 Jul 2003 17:30:30 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Daniel" == Daniel Senie <[email-masked]> writes:

    >> But, a DNS server will be?

    Daniel> Reality check: home networks are, if connected to the Internet,
    Daniel> attached via a gatewaying device. The de vice of choice for a
    Daniel> large number of networks is a $60 router from on of any number of
    Daniel> vendors. These boxes provide DHCP, DNS forwarding and
    Daniel> NAT. Perhaps some other environment would provide a better
    Daniel> strawman? DHCP is pretty prevalent in home networks.  

  Right, exactly.

  I simply do not believe that there are environments where there will be
a local (on wire) DNS server, but not a local DHCP server. The home
environment is entirely the opposite - local DHCP server in SOHO router
that gets the DNS info from the ISP via DHCP and/or PPP and passes it on via
DHCP.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 27 Jul 2003 19:52:29 +0859 ()

> that gets the DNS info from the ISP via DHCP and/or PPP and passes it on via

Right.

Assuming that there is DHCP server even at home, there is no reason
to have stateless (nor statefull) autoconfiguration by ND, which is
why IPv6 is broken.

However, there is still some configuration required at home to
let the local DHCP server gets the ISP via DHCP, but definitely
not by PPP, because PPP is for dial up over non-IP infrastructure.

The simple way for home environment is to to let ISPs offer the DNS
servers for their customer sites, which was impossible with
addresses with site local scope.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 27 Jul 2003 20:22:00 +0859 ()

Right.

And, having such DHCP servers, there is no role of RA for stateless
(nor stateful) autoconfiguration, which is why IPv6 with ND is broken.

The remaining problem is configuration on how to let the DHCP
server in SOHO router get the info and the solution should be
related to anycast.

DNS server with anycast addresses does not neet intermediate DHCP.

							Masataka Ohta

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 27 Jul 2003 08:00:43 -0500

> addresses with site local scope.

This entire debate has only convinced me that what we really need is
(real) multicast-capable DNS resolvers and protocols (real DNS, not a
substitute service).

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Soohong Daniel Park <[email-masked]>
Date: Tue, 29 Jul 2003 10:56:33 +0900

Please be sure that we didn't focus on only SOHO/Homenetwork.
I guess RA-based mechanism is more efficient in mobility than any cases.
Therefore, I would like say that we need both mechanisms for each
application domain.

Daniel (Soohong Daniel Park)
Mobile Platform Lab,SAMSUNG Electronics

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Masataka Ohta
> Sent: Sunday, July 27, 2003 7:53 PM
> To: Michael Richardson
> Cc: [email-masked]
> Subject: Re: proposal for a compromise on DNS discovery
> 
> 
> >   I simply do not believe that there are environments where 
> there will 
> > be a local (on wire) DNS server, but not a local DHCP 
> server. The home 
> > environment is entirely the opposite - local DHCP server in SOHO 
> > router that gets the DNS info from the ISP via DHCP and/or PPP and 
> > passes it on via DHCP.
> 
> Right.
> 
> Assuming that there is DHCP server even at home, there is no 
> reason to have stateless (nor statefull) autoconfiguration by 
> ND, which is why IPv6 is broken.
> 
> However, there is still some configuration required at home 
> to let the local DHCP server gets the ISP via DHCP, but 
> definitely not by PPP, because PPP is for dial up over non-IP 
> infrastructure.
> 
> The simple way for home environment is to to let ISPs offer 
> the DNS servers for their customer sites, which was 
> impossible with addresses with site local scope.
> 
> 							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Jul 2003 10:58:14 +0859 ()

Eric A. Hall;

> (real) multicast-capable DNS resolvers and protocols (real DNS, not a

Huh? Multicast? It's no solution. As I commented to

	Message-Id: <[email-masked]>
	Subject: Re: DNS discovery discussion
	To: Ralph Droms <[email-masked]>
	CC: [email-masked]
	Date: Thu, 24 Jul 2003 13:46:31 +0859 ()

	By assuming large link layer, which violates the CATENET model,
	many protocols, including but not limited to IPv6 and IGMP,
	are damaged.

	Now, we can simply say, broadcast.

link local multicast is a poor alternative to broadcast.

In addition, DNS with link local multicast/broadcast does not solve
any configuration problem.

Multicast for domains larger than a link beyond routers requires
domain wide broadcast (such as that of data broadcast of DVMRP
or core/RP selction of CBT/PIM) or static configuration (such as that
of core/RP/source of CBT/PIM/SSM).

The confdiguraed data is different site by site, unless you use
anycast for core/RP/source. But, no one is sure what will happen
with this kind of combination of anycast and multicast that this
is not the way to go.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Jul 2003 11:33:33 +0859 ()

Daniel (Soohong Daniel Park);

> Please be sure that we didn't focus on only SOHO/Homenetwork.

Then, can you clarify your requirement?

> I guess RA-based mechanism is more efficient in mobility than any cases.

What kind of autoconfiguration, do you think, is helpful for a
mobile host?

Remember that the mobile host MUST have *CONFIGURED* relationship
and good connectivity with its home agent (or something like that)
and environment around the home agent.

							Masataka Ohta

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 29 Jul 2003 09:22:06 -0500

> link local multicast is a poor alternative to broadcast.

I don't understand these complaints. ~512 bytes isn't very large, and
broadcast is a poor alternative to admin scoped multicast.

> any configuration problem.

Which configuration problem? It wouldn't give a hostname if that's what
you mean, but I'm not sure that anybody would expect such.

> of core/RP/source of CBT/PIM/SSM).

It would need static configuration in a non-optimized state. One of the
challenges for a multicast DNS would be to keep multiple servers from
always replying to every query, and that could be accomplished through
numerous methods, any of which may in turn could minimize the need for
manual maintenance of the multicast address.

It's also possible to limit the use of multicast to DNS discovery, such as
having clients issue (periodic) queries to the multicast address to
determine the available servers, and to choose the top 3 servers (or
whatever) based on certain criteria (RA flag, response time, whatever),
and then use unicast after that.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Jul 2003 11:12:07 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Soohong" == Soohong Daniel Park <[email-masked]> writes:
    Soohong> Please be sure that we didn't focus on only SOHO/Homenetwork.  I
    Soohong> guess RA-based mechanism is more efficient in mobility than any
    Soohong> cases.  Therefore, I would like say that we need both mechanisms
    Soohong> for each application domain.

  Mobility to *where*?

  It isn't the mobility that is the question, it is what services are present
at the location where one is dropping in to.

  RA is very useful for places where no admission control is present or
expected - so no prior configuration is likely or desireable. yet, the
network is so small, or so ad-hoc that there really is *ONLY* the router.
No printers. No NTP servers. No local SMTP relays. Yet, it is postulated
that there is a local DNS server of some kind. One that is not anycast'able.

  Which networks are these?  Not the IETF network. Not my SOHO network.
  Not most commercial wireless networks nor xDSL or cable networks.
(they have admission control)

  So, which networks need this?

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 29 Jul 2003 11:20:14 -0500

> and then use unicast after that.

I've submitted an I-D on this in particular, which is also available at
http://www.ehsco.com/misc/draft-hall-resolver-config-00.txt

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 30 Jul 2003 14:51:11 +0859 ()

Eric A. Hall;

> http://www.ehsco.com/misc/draft-hall-resolver-config-00.txt

Your draft is excellent to say:
      
     This specification is intended to address the narrow scenario 
     where a host needs to determine the DNS servers which are willing 
     to provide DNS resolution services to that host. This document 
     does not define any additional services. 

Are there anyone who still have more bloated requirements?

> > and then use unicast after that.

And if you specify all the details of protocol changes, the only
remaining problem is autoconfiguration of multicast.

							Masataka Ohta