RE: [dhcwg] DHCP Option for CableLabs Client Configuration

["Woundy, Richard" <[e-mail]>]

(I trimmed the cc list somewhat)

Erik Nordmark and I had an offline conversation yesterday, where we came to
the following conclusion. If a service provider (e.g. cable operator) need
to run multiple DNS servers on the same server box/chassis, in order to
support independent DNS services (e.g. one for Internet access, another for
Voice over IP), then we can assume that the service provider can run
multiple DNS servers "bound" to different IP addresses assigned to the
box/chassis, rather than "bound" to different UDP ports for DNS services.
That is, each new DNS server on the same box/chassis costs another unique IP
address.

For a concrete instantiation of this assumed functionality, please consider
the BIND documentation for the "listen-on" configuration option, e.g.
section 6.2.14.4 of
<http://www.nominum.com/resources/documentation/Bv9ARM.pdf>. It would be
helpful to hear about other DNS servers with this capability.

Following this assumption, my understanding is that the authors of the
CableLabs Client Configuration DHCP option internet-draft will remove the
domain name server address suboptions (4 and 5) from the next version of the
draft, and the PacketCable VoIP endpoints (aka MTAs, sorry Ted ;^) will use
standard DHCP option 6 to obtain domain name server addresses.

If there is a need for many DNS servers to be co-located on the same
box/chassis (which does not appear to be the case today), consuming an
unreasonable number of unique IP addresses, then the issue of configuring
non-standard DNS port numbers for clients might be revisited, perhaps in a
wider context than just cable networks.

Please respond to this email if these assumptions are incorrect --
especially if this isn't going to work!

-- Rich

-----Original Message-----
From: Erik Nordmark [mailto:[e-mail]]
Sent: Wednesday, August 07, 2002 5:04 AM
To: Woundy, Richard
Cc: 'Erik Nordmark'; Josh Littlefield; Paul Duffy; Thomas Narten; Bernie
Volz (EUD); 'Ralph Droms'; [e-mail]; [e-mail];
[e-mail]; Matt Osman
Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration


> Are you suggesting that if folks in the cable world still believe that
there
> is a requirement to communicate DNS port numbers to MTAs, then they should
> define an additional Internet draft that is published as Experimental or
> Informational?

Depends on the ellusive details.

It would be better if they could clearly communicate the requirement so that
the IETF can look at it and try to understand what type of reqirement it
is and whether or not it is a requirement specific to the cablelabs type
of environment. 

If the requirement is that for testing purposes or experimentation 
in the cablelabs environments it is useful to be able to use different port
numbers for DNS, then a separate info or experimental document would make
sense. But I can't yet tell whether this is the case.

> Note that the PacketCable specifications themselves, and the long-term
> intent of the CableLabs Config option, is to enable VoIP services beyond
> "walled garden" services. We are just talking about part of the DHCP
option
> information in that draft, no?

Yes. Thomas had some issues with the other suboptions, but my concerns
is about the DNS.

> I don't quite understand the issue of non-interoperability. If an RFC
> explains the expected DNS behavior of the MTA, and there are multiple
> implementations that support that expected DNS behavior in DNS servers,
> then... what's the issue again?

There is in theory potential interoperability issues both for DHCP and DNS.
DHCP: will things operate correctly if the MTA receives a good ol' DNS
name server option instead of this suboption? If not you either get all
the DHCP servers on the planet to implement the cablelabs option or you
could
end up with interoperability problems.
DNS: will things operate correctly if the MTA is using the standard DNS
port?
If not you either get all the DNS resolvers on the planet to be configurable
to run on an alternate port, you could end up with interoperability
problems.

Of course, by careful selection of parts (DHCP servers, DNS resolvers) for
a cablelabs environment one can avoid these problems. But part of the
benefits
of the Internet interoperability story is that it doesn't require special
versions of protocols and software; things off the shelf just tend to
interoperate. This off-the-shelf aspect and the price of equipment that
results is often a key perceived benefit of using the internet protocols.
So let's think a bit before embarking on paths that break this.

> The biggest advantage is that a cable operator could run multiple DNS
> servers on the same hardware, with separate administrative tools, run by
> possibly independent operations folks. There would be no issues about the
> impacts of one DNS service configuration change on the other DNS service.
> Both DNS services could be verified independently, without the need of
> performing DNS queries "from the right location for the right test".

Thank you!!! It's something concrete like this that I've been looking for
all along.

Have people been thinking about this when there are only two DNS servers
on the box (one for the best-effort IP network and one for the VoIP
network),
or have people also been thinking about outsourcing cases where a
single DNS box might provide DNS service for multiple VoIP networks run by
different operators? I think understanding whether it can be more than 2
in a box might be important.

  Erik


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