RE: [dhcwg] DHCP Option for CableLabs Client Configuration

[Paul Duffy <[e-mail]>]

Thanks Patrick...inline...

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

>Is the argument that DHCP needs to be used to configure non-standard DNS 
>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


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

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.
>
>
>-----Original Message-----
>From: Paul Duffy [<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Thursday, August 01, 2002 4:01 PM
>To: Erik Nordmark
>Cc: Thomas Narten; Bernie Volz (EUD); 'Ralph Droms'; [e-mail];
>[e-mail]; [e-mail]; 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.
>[e-mail]
>
>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg 
>

--

Paul Duffy
Cisco Systems, Inc.
[e-mail]