Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration

From: "Cosmo, Patrick" <[email-masked]>
Date: Fri, 2 Aug 2002 12:44:13 -0700

Is the argument that DHCP needs to be used to configure non-standard DNS
ports because DHCP occurs at the initial stages of provisioning? That SNMP
and/or the MTA configuration file cannot be used to configure non-standard
DNS ports because SNMP occurs too late in the provisioning process and/or
the config file is downloaded to late in the provisioning process (meaning
that DNS may required in order to be able to perform SNMP or to download the
configuration file)?

Is the argument for sub-options 1/2 that you need to be able to configure
one DHCP service such that it will respond to MTA DHCP traffic, but will
tell those MTAs to use some other DHCP service (in effect "redirect" the MTA
to another DHCP)? Why would you want this? If you can configure the DHCP
service to know which MTAs to "redirect", why can't you just configure the
DHCP service to ignore those MTAs altogether, instead of "redirecting" them,
so that the MTAs only recieve OFFERs from the appropriate DHCP services? I
believe that this is the way the rest of the world has always worked up
until now: if you don't want a device to get a lease from a particular DHCP
service, you configure that DHCP service so it doesn't offer those devices a
lease. You don't configure the DHCP service to send an offer that basically
says "I'm offering a lease, but you are not allowed to accept any leases
from me, you must except leases only from DHCP server X". It could be that
I'm misunderstanding the purpose of these options.

-----Original Message-----
From: Paul Duffy [mailto:[email-masked]]
Sent: Thursday, August 01, 2002 4:01 PM
To: Erik Nordmark
Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; [email-masked];
[email-masked]; [email-masked]; Matt Osman
Subject: Re: [dhcwg] DHCP Option for CableLabs Client Configuration 

Thanks Erik,

Re: optional port numbers ...

1. Cablelabs needs it for testing, lab, etc.
2. Some MSO's may decide to deploy DNS on non standard ports.  Its a 
flexibility issue.
3. Not using a standard port makes it slightly less prone to attack by 
script kiddies.

...I'm out of arguments.   What specific suggestions do you have would give 
us the port configuration control ?

Thanks,

At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote:
> > 1.  A primary use case is for testing/lab/trial deployments.  The only
way
> > to configure an MTA (a headless, embedded device) for a non standard
port
> > number would be via the CCC sub-option 4/5 mechanism.
>
>That seems like an argument for perhaps an experimental RFC, but
>as I understand it the intent is to make this specification a proposed
>standard.
>
> > 2. Permitting protocol servers to run on a non standard port is not 
> without
> > precedence.  Its been pointed out that Paul Vixie's "named" server
allows
> > it to be configured on a specific port. Does this mean that Paul is
> > violating Internet Standards ?  Come to think of it, I don't think I've
> > ever seen a protocol server that did not permit configuration of its
> > protocol port.
>
>I don't think anybody has claimed that servers must always use the
>standard port number.
>
>Instead the issue seems to be that the sole reason that these suboptions
>are needed i.e. why the standard DHCP options for DNS servers are not
>sufficient. is the claimed need to support non-standard port numbers.
>
>Why invent a new standard mechanism for this, especially since the utility
>is limited to testing/lab/trials?
>
>   Erik

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

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

---

From: Paul Duffy <[email-masked]>
Date: Fri, 02 Aug 2002 16:09:52 -0400

Thanks Patrick...inline...

At 12:44 PM 8/2/2002 -0700, Cosmo, Patrick wrote:

>ports because DHCP occurs at the initial stages of provisioning?

Yes

>That SNMP and/or the MTA configuration file cannot be used to configure 
>non-standard DNS ports because SNMP occurs too late in the provisioning 
>process and/or the config file is downloaded to late in the provisioning 
>process (meaning that DNS may required in order to be able to perform SNMP 
>or to download the configuration file)?

Exactly

>tell those MTAs to use some other DHCP service (in effect "redirect" the 
>MTA to another DHCP)?

No.  The access provider's DHCP server sends a list of legal telephony DHCP 
server addresses (CCC sub options 1/2) to the CM.  The CM passes this list 
to the MTA  (both devices live in the same physical box).  The MTA does a 
normal discover, but uses the list to restrict the set of DHCP servers from 
which it will accept DHCP responses.  See section 7 
http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.pdf

<key issue>
You have an access provider who has tight control over its DHCP/DNS 
infrastructure.  The access provider is permitting other business entities 
to layer services atop its network.  The access provider will have less 
control over the service provider's infrastructure.
</key issue>

The 1/2 mechanism explicitly scopes specific devices to specific service 
provider's infrastructure.  It also offers some what more protection from 
the hacker who is trying to setup a bogus DHCP server behind his cable 
modem, potentially bringing down the phones.  Not good if your house is 
burning down and you need to call the fire department.

>Why would you want this? If you can configure the DHCP service to know 
>which MTAs to "redirect", why can't you just configure the DHCP service to 
>ignore those MTAs altogether, instead of "redirecting" them, so that the 
>MTAs only recieve OFFERs from the appropriate DHCP services? I believe 
>that this is the way the rest of the world has always worked up until now: 
>if you don't want a device to get a lease from a particular DHCP service, 
>you configure that DHCP service so it doesn't offer those devices a lease. 
>You don't configure the DHCP service to send an offer that basically says 
>"I'm offering a lease, but you are not allowed to accept any leases from 
>me, you must except leases only from DHCP server X". It could be that I'm 
>misunderstanding the purpose of these options.
>
>
>From: Paul Duffy [<mailto:[email-masked]>mailto:[email-masked]]
> > > 1.  A primary use case is for testing/lab/trial deployments.  The 
> only way
><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg 
>

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: "Cosmo, Patrick" <[email-masked]>
Date: Fri, 2 Aug 2002 14:34:21 -0700

The access provider's DHCP server sends a list of legal telephony DHCP
server addresses (CCC sub options 1/2) to the CM.  The CM passes this list
to the MTA  (both devices live in the same physical box). 
[Cosmo, Patrick] The CM must be completely provisioned before the MTA can
(successfully) do DHCP, correct? So why can't you send the sub-option 1/2
data to the CM in its config file or through SNMP, and then let it pass it
along to the MTA? 
 
You want to ensure that the MTA gets a list of "legal telephony DHCP server
addresses". This implies that without opts 1/2, the MTA may get DHCP from a
server outside this list. Can anyone say whether there is a mechanism that
ensures the CM only gets DHCP from valid servers (does the CMTS ensure
this?)? This question has already been posited to Richard Woundy, but
perhaps someone else knows? You can't protect the MTA from bogus DHCP
servers, if you are trying to do it using data, forwarded from a CM, that
originates from those same bogus DHCP servers. Similarly, this opt 1/2
mechanism does not allow the access provider to gain tighter control over
its DHCP/DNS infrastructure if the CM can get DHCP from servers outside this
infrastructure.
 
  The MTA does a normal discover, but uses the list to restrict the set of
DHCP servers from which it will accept DHCP responses.  See section 7
http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.
<http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.pdf>  pdf
<http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.pdf> 

<key issue>

Why would you want this? If you can configure the DHCP service to know which
MTAs to "redirect", why can't you just configure the DHCP service to ignore
those MTAs altogether, instead of "redirecting" them, so that the MTAs only
recieve OFFERs from the appropriate DHCP services? I believe that this is
the way the rest of the world has always worked up until now: if you don't
want a device to get a lease from a particular DHCP service, you configure
that DHCP service so it doesn't offer those devices a lease. You don't
configure the DHCP service to send an offer that basically says "I'm
offering a lease, but you are not allowed to accept any leases from me, you
must except leases only from DHCP server X". It could be that I'm
misunderstanding the purpose of these options.

-----Original Message----- 
From: Paul Duffy [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, August 01, 2002 4:01 PM 
To: Erik Nordmark 
Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; [email-masked]; 

Thanks Erik, 

Thanks, 

way 
port 
allows 

-- 

Paul Duffy 
Cisco Systems, Inc. 
[email-masked] 

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

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: "Cosmo, Patrick" <[email-masked]>
Date: Fri, 2 Aug 2002 15:31:29 -0700

Thanks Ralph. Does it only prevent DHCP server spoofing for CMs, and not
MTAs? 

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Friday, August 02, 2002 6:18 PM
To: Cosmo, Patrick
Cc: 'Paul Duffy'; PacketCable Provisioning and OSS Majordomo List; Erik
Nordmark; Thomas Narten; Bernie Volz (EUD); [email-masked];
[email-masked]; [email-masked]; Matt Osman
Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration 

Patrick - 

In response to the question at the beginning of your second paragraph, the
CMTS is responsible for preventing DHCP server spoofing.  See section 4 of
"Cable Modem Termination System - Network Side Interface Specification",
SP-CMTS-NSII01-960702.

- Ralph

At 02:34 PM 8/2/2002 -0700, Cosmo, Patrick wrote:

 

<key issue>

-----Original Message----- 

To: Erik Nordmark 

Thanks Erik, 

flexibility issue. 

script kiddies. 

Thanks, 

way 

port 

allows 

-- 

Paul Duffy 

Cisco Systems, Inc. 

[email-masked] 

dhcwg mailing list 

[email-masked] 

--

Paul Duffy 

Cisco Systems, Inc. 

[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Fri, 02 Aug 2002 18:18:03 -0400

Patrick -

In response to the question at the beginning of your second paragraph,
the CMTS is responsible for preventing DHCP server spoofing.  See
section 4 of "Cable Modem Termination System – Network Side
Interface Specification", SP-CMTS-NSII01-960702.

- Ralph

The access provider's DHCP server sends a list
of legal telephony DHCP server addresses (CCC sub options 1/2) to the
CM.  The CM passes this list to the MTA  (both devices live in
the same physical box).

[Cosmo, Patrick] The CM must be
completely provisioned before the MTA can (successfully) do DHCP,
correct? So why can't you send the sub-option 1/2 data to the CM in its
config file or through SNMP, and then let it pass it along to the MTA?

You want to ensure that the MTA
gets a list of "legal telephony DHCP server addresses". This
implies that without opts 1/2, the MTA may get DHCP from a server outside
this list. Can anyone say whether there is a mechanism that ensures the
CM only gets DHCP from valid servers (does the CMTS ensure this?)? This
question has already been posited to Richard Woundy, but perhaps someone
else knows? You can't protect the MTA from bogus DHCP servers, if you are
trying to do it using data, forwarded from a CM, that originates from
those same bogus DHCP servers. Similarly, this opt 1/2 mechanism does not
allow the access provider to gain tighter control over its DHCP/DNS
infrastructure if the CM can get DHCP from servers outside this
infrastructure.

The MTA does a normal discover, but uses the list to restrict the
set of DHCP servers from which it will accept DHCP responses.  See
section 7
http://www.packetcable.com/specs/PKT-SP-PROV-I03-011221.pdf

<key issue>

You have an access provider who has tight control over its DHCP/DNS
infrastructure.  The access provider is permitting other business
entities to layer services atop its network.  The access provider
will have less control over the service provider's infrastructure.

</key issue>

The 1/2 mechanism explicitly scopes specific devices to specific service
provider's infrastructure.  It also offers some what more protection
from the hacker who is trying to setup a bogus DHCP server behind his
cable modem, potentially bringing down the phones.  Not good if your
house is burning down and you need to call the fire department.

Why would you want this? If you can configure the DHCP service to
know which MTAs to "redirect", why can't you just configure the
DHCP service to ignore those MTAs altogether, instead of
"redirecting" them, so that the MTAs only recieve OFFERs from
the appropriate DHCP services? I believe that this is the way the rest of
the world has always worked up until now: if you don't want a device to
get a lease from a particular DHCP service, you configure that DHCP
service so it doesn't offer those devices a lease. You don't configure
the DHCP service to send an offer that basically says "I'm offering
a lease, but you are not allowed to accept any leases from me, you must
except leases only from DHCP server X". It could be that I'm
misunderstanding the purpose of these options.

-----Original Message-----

From: Paul Duffy
[mailto:[email-masked]]

To: Erik Nordmark

Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms';
[email-masked];

Thanks Erik,

flexibility issue.

script kiddies.

Thanks,

At 07:12 PM 8/1/2002 +0200, Erik Nordmark wrote:

> > 1.  A primary use case is for testing/lab/trial deployments.  The only way

> > to configure an MTA (a headless, embedded device) for a non standard port

> > precedence.  Its been pointed out that Paul Vixie's "named" server allows

--

Paul Duffy

Cisco Systems, Inc.

[email-masked]

dhcwg mailing list

[email-masked]

--

Paul Duffy

Cisco Systems, Inc.

[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Fri, 02 Aug 2002 18:28:55 -0400

Patrick,

>Thanks Ralph. Does it only prevent DHCP server spoofing for CMs, and not 

Good question; the text reads:

Network layer requirements for the CMTS exist beyond transparency to IP 
traffic. The CMTS
must also support:

· variable length subnet masks
· classless addressing
· IP multicast addressing and forwarding
· Internet Group Management Protocol (IGMP)
· proxy ARP
· filtering of DHCP downstream-bound broadcast packets to protect against 
BOOTP server spoofing

I would read the text to apply to all DHCP server spoofing.

- Ralph

>>server addresses (CCC sub options 1/2) to the CM.  The CM passes this 
>>list to the MTA  (both devices live in the same physical box).
>>data to the CM in its config file or through SNMP, and then let it pass 
>>it along to the MTA?
>>
>>You want to ensure that the MTA gets a list of "legal telephony DHCP 
>>server addresses". This implies that without opts 1/2, the MTA may get 
>>DHCP from a server outside this list. Can anyone say whether there is a 
>>mechanism that ensures the CM only gets DHCP from valid servers (does the 
>>CMTS ensure this?)? This question has already been posited to Richard 
>>Woundy, but perhaps someone else knows? You can't protect the MTA from 
>>bogus DHCP servers, if you are trying to do it using data, forwarded from 
>>a CM, that originates from those same bogus DHCP servers. Similarly, this 
>>opt 1/2 mechanism does not allow the access provider to gain tighter 
>>control over its DHCP/DNS infrastructure if the CM can get DHCP from 
>>servers outside this infrastructure.
>>
>>   The MTA does a normal discover, but uses the list to restrict the set 
>> of DHCP servers from which it will accept DHCP responses.  See section 7 
>>entities to layer services atop its network.  The access provider will 
>>have less control over the service provider's infrastructure.
>></key issue>
>>
>>>which MTAs to "redirect", why can't you just configure the DHCP service 
>>>to ignore those MTAs altogether, instead of "redirecting" them, so that 
>>>the MTAs only recieve OFFERs from the appropriate DHCP services? I 
>>>until now: if you don't want a device to get a lease from a particular 
>>>DHCP service, you configure that DHCP service so it doesn't offer those 
>>>devices a lease. You don't configure the DHCP service to send an offer 
>>>that basically says "I'm offering a lease, but you are not allowed to 
>>>accept any leases from me, you must except leases only from DHCP server 
>>>X". It could be that I'm misunderstanding the purpose of these options.

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 2 Aug 2002 16:27:34 -0600

Folks,
 
It does not seem to be good engineering practice to use CCC suboptions 1/2
as an alternative to DHCP message authentication, ala RFC3118. So I do not
think it is reasonable to expect these suboptions to protect the MTAs from
"bogus DHCP servers" completely.
 
I believe the right way to think about these suboptions is in the context of
RFC 2131 section 4.1.1:
 
   The client collects DHCPOFFER messages over a period of time, selects
   one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
   messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
   from the previously used server) and extracts the server address from
   the 'server identifier' option in the DHCPOFFER message.  The time
   over which the client collects messages and the mechanism used to
   select one DHCPOFFER are implementation dependent.
 
In essense, the value(s) in CCC suboptions 1/2 provide additional criteria
for the "mechanism used to select one DHCPOFFER". That is, the values of the
suboptions constrain the choice of DHCPOFFERs to messages for which the
"server identifier" option matches one of the suboptions values (the value
255.255.255.255 being excepted of course).
 
This isn't as new a concept as it might sound. There is already text in
RFC2131 about clients basing their choice of DHCPOFFERs based on the "vendor
class identifier" option. Section 4.3.1 says "The server MAY choose to
return the 'vendor class identifier' used to determine the parameters in the
DHCPOFFER message to assist the client in selecting which DHCPOFFER to
accept."
 
The reason this capability exists in PacketCable is because when a device
(cable modem, personal computer, MTA) transmits a DHCP broadcast message,
the upstream router can relay the DHCP message to multiple DHCP servers in
different administrative domains, and the device needs some help in choosing
among multiple (legitimate) DHCPOFFERs. The Telephony Service Provider (TSP)
might be a different organization than the Access Provider (AP), and there
may be multiple TSPs. If a PacketCable MTA ought to receive service from
TSP-1, and the MTA sends a DHCP broadcast message that is relayed by the
CMTS to both TSP-1 and TSP-2 DHCP servers, the MTA needs to know that it
should ignore the DHCP responses from TSP-2.
 
Why would the TSP-2 DHCP server respond, if TSP-1 provides telephony service
for the MTA? One possibility is that TSP-2 might enable a self-provisioning
service for unknown MTAs -- allow the MTA to boot on TSP-2 with just enough
privileges to contact a (real or virtual) service representative to sign up
for service. Similar functionality for Internet service has already been
deployed in cable networks today. A second possibility is to allow the MTA
to boot on a limited TSP network for 911 calls only.
 
-- Rich
 
P.S. There are a number of mechanisms that cable operators leverage to
prevent rogue DHCP servers from attacking their customers, i.e. spoofing the
operator's DHCP servers. A key mechanism is IP network filtering function
provided in routers and cable modems (see RFC 2669 for details). That serves
mostly as a perimeter defense. Some scalable form of DHCP message
authentication would be preferable, though.
 
P.P.S. Gee, don't I get more than one hour to respond to random emails
directed towards me???

-----Original Message-----
From: Cosmo, Patrick [mailto:[email-masked]]
Sent: Friday, August 02, 2002 5:34 PM
To: 'Paul Duffy'; PacketCable Provisioning and OSS Majordomo List
Cc: Erik Nordmark; Thomas Narten; Bernie Volz (EUD); 'Ralph Droms';
[email-masked]; [email-masked]; [email-masked]; Matt Osman
Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration

 

<key issue>

-----Original Message----- 
From: Paul Duffy [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, August 01, 2002 4:01 PM 
To: Erik Nordmark 
Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; [email-masked]; 

Thanks Erik, 

Thanks, 

way 
port 
allows 

-- 

Paul Duffy 
Cisco Systems, Inc. 
[email-masked] 

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Sat, 3 Aug 2002 17:29:32 -0700

Hi,

	[Cosmo, Patrick] The CM must be completely provisioned before the MTA can (successfully) do DHCP, correct? So why can't you send the sub-option 1/2 data to the CM in its config file or through SNMP, and then let it pass it along to the MTA? 
	[sumanth] Not sure if I can answer this - there were various possible ways of doing it, however, changing the DOCSIS spec was not a sought after option and we had a suboption being introduced for PCBL which could be easily re-used with minimal changes. Besides it was not necessary to 'protect this info' as we havent addressed DHCP security.

	You want to ensure that the MTA gets a list of "legal telephony DHCP server addresses". This implies that without opts 1/2, the MTA may get DHCP from a server outside this list. Can anyone say whether there is a mechanism that ensures the CM only gets DHCP from valid servers (does the CMTS ensure this?)? This question has already been posited to Richard Woundy, but perhaps someone else knows? You can't protect the MTA from bogus DHCP servers, if you are trying to do it using data, forwarded from a CM, that originates from those same bogus DHCP servers. Similarly, this opt 1/2 mechanism does not allow the access provider to gain tighter control over its DHCP/DNS infrastructure if the CM can get DHCP from servers outside this infrastructure.
	 
	[sumanth] I guess Rich answered the Q on DHCP servers.
	 
	However, in case of Packetcable the architecture kept in mind that there could potentially be 'different' data and telephony service providers' using the same 'embedded' device ( EMTA ). This would mean that the 'data service provider' and the 'telephony service provider' could use different 'backoffice components' - which means that valid DHCP servers can
	still affect each others n/w - given that the MTAs come from behind the same MTA and mostly recognised as 'CPEs'
	- meaning multiple DHCP servers might have the same scopes.
	 
	To avoid any such scenarios it is advisable to let the MTA know which servers it could accept the OFFERs from and
	ofcourse you can have values like 255.255.255.255 if it does not apply.
	( Ofcourse, there are other ways to accomplish the same - this was what was chosen ). 
	 
	regards
	Sumanth

---

From: "Cosmo, Patrick" <[email-masked]>
Date: Thu, 8 Aug 2002 08:11:32 -0700

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

Incognito's DNS Commander has this capability (www.incognito.com)

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
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'; [email-masked]; [email-masked];
[email-masked]; 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