Protokol Konfigurasi Hos Dinamik

Sejarah

DHCP pertama kali ditakrifkan sebagai trek protokol piwaian dalam RFC 1531 pada bulan Oktober 1993, sebagai perluasan kepada Protocol Bootstrap (BOOTP). Motivasi untuk memperluaskan BOOTP adalah BOOTP memerlukan campur tangan manual untuk menambah maklumat tatarajah bagi setiap pelanggan, dan tidak menyediakan mekanisme untuk mengambil kembali alamat IP yang tidak digunakan.
Banyak usaha telah dilakukan untuk menjelas protokol ketika ia semakin popular, dan pada 1997 RFC 2131 dikeluarkan, dan kekal menjadi piwaian untuk rangkaian IPv4. DHCPv6 didokumentasikan di RFC 3315. RFC 3633 menambah satu mekanisme DHCPv6 untuk awalan delegasi. DHCPv6 telah dikembangkan lebih lanjut untuk memberikan maklumat tatarajah bagi pelanggan menatarajah menggunakan autokonfigurasi tanpa alamat di RFC 3736.
Protokol BOOTP sendiri pertama kali ditakrifkan dalam RFC 951 sebagai pengganti Protokol Penyelesai Alamat Songsang ("Reverse Address Resolution Protocol-RARP".) Motivasi utama untuk menukar RARP dengan BOOTP adalah bahawa RARP adalah protokol lapis sambungan data. Hal ini menyulitkan pelaksanaan di kebanyakan platform pelayan, dan memerlukan pelayan terdapat pada setiap sambungan rangkaian individu. BOOTP memperkenalkan inovasi agen geganti, yang membolehkan paket BOOTP dihantar ke rangkaian tempatan dengan menggunakan routing IP piwaian, agar satu pusat pelayan BOOTP boleh melayani hos banyak subrangkaian IP.

Perincian teknikal

DHCP menggunakan dua port yang sama ditetapkan oleh IANA bagi BOOTP: 67/udp bagi menghantar data kepada pelayan, dan 68/udp bagi data kepada pelanggan.
Operasi DHCP gagal kedalam empat fasa asas: Jumpaan IP, tawaran sewa IP, permohonan IP, dan akuan sewa IP.
Sekiranya pelanggan DHCP dan pelayan berada pada subrangkaian yang sama, mereka akan berhubung melalui sebaran UDP. Apabila pelanggan dan pelayan berada subrangkaian yang berlainan, perutusan jumpaan IP dan permohonan IP dihantar melalui sebaran UDP, tetapi perutusan tawaran sewa IP dan akuan sewa IP dihantar melalui unicast.

DHCP information

A DHCP client may request more information than the server sent with the original DHCPOFFER. The client may also request repeat data for a particular application. For example, browsers use DHCP Inform to obtain web proxy settings via WPAD. Such queries do not cause the DHCP server to refresh the IP expiry time in its database.

DHCP releasing

The client sends a request to the DHCP server to release the DHCP information and the client deactivates its IP address. As client devices usually do not know when users may unplug them from the network, the protocol does not mandate the sending of DHCP Release.

Client configuration parameters in DHCP

A DHCP server can provide optional configuration parameters to the client. RFC 2132 describes the available DHCP options defined by Internet Assigned Numbers Authority (IANA) - DHCP and BOOTP PARAMETERS.
A DHCP client can select, manipulate and overwrite parameters provided by a DHCP server.

Pilihan

Pilihan ada masakini bagi mengenal pasti vendor dan fungsi pelanggan DHCP. Maklumat ini adalah rangkaian huruf pelbagai panjang atau octets yang mempunyai maksud khusus yang ditetapkan oleh pembekal kepada pelanggan DHCP. Satu kaedah adalah pelanggan DHCP boleh menggunakan untuk berhubung dengan pelayan bahawa ia menggunakan hardware atau firmware tertentu adalah dengan memasukkan nilai dalam permohonan DHCPnya yang dikenali sebagai Pengenal pasti Kelas Vendor (Vendor Class Identifier-VCI) (Option 60). kaedah ini membolehkan pelayan DHCP untuk membezakan antara dua jenis mesin pelanggan dan memproses permohonan dari dua jenis modem dengan betul. Sesetengah jenis kotak set-top turut memasukkan VCI (Option 60) untuk memberitahu pelayan DHCP mengenai jenis hardware dan fungsi perantinya. Nilai yang digunakan oleh pilihan ini memberikan pelayan DHCP bayangan mengenai sebarang permohonan maklumat tambahan yang diperlukan pelanggan dalam balasan DHCP.

Gegantian DHCP

Dalam rangkaian DHCP kecil biasanya menggunakan penyiaran alamat. Bagaimanapun, dalam sesetengah keadaan, alamat unisiar akan digunakan, sebagai contoh: apabila rangkaian memiliki pelayan DHCP tunggal yang memberikan alamat IP bagi banyak subrangkaian. Apabila penghala bagi subjarangan sedemikian menerima siaran DHCP, ia menukar dirinya kepada unisiar (dengan matlamat MAC/alamat IP bagi tatarajah pelayan DHCP, suMAC/IP bagi penghala itu sendiri). Bidang GIADDR bagi permohonan disunting ini diisi dengan alamat IP bagi antaramuka penghala padanya ia menerima permohonan DHCP asal. Pelayan DHCP menggunakan bidang GIADDR bagi mengenalpasti subjaringan peranti asal bagi memilih alamat IP dari kumpulan yang betul. Pelayan DHCP kemudiannya menghantar TAWARAN DHCP ("DHCP OFFER") kembali ke penghala melalui unisiar. Penghala kemudiannya menukar TAWARAN DHCP kembali kepada siaran, dihantar pada antaramuka pada peranti asal.

Keutuhan

Piwaian bagi melaksanakan reka bentuk tahan rosak pelayan DHCP telah dibincangkan oleh Internet Engineering Task Force, tetapi piwaian lakar telah luput. Piwaian lakar mencadangkan pelayan berganda, satu utama dan satu sokongan. Pelayan sokongan menjejak pemberian alamat IP yang dibuat oleh pelayan utama dan mengambil aluk sekiranya pelayan utama gagal.