Protokol Konfigurasi Hos Dinamik
| Suit protokol Internet |
|---|
| Lapisan Penggunaan |
| Lapisan Pengangkutan |
| Lapisan Internet |
| Lapisan Pautan |
Protokol Konfigurasi Hos Dinamik (Dynamic Host Configuration Protocol - DHCP)[1] merupakan protokol tatarajah automatik yang digunakan pada rangkaian IP. Komputer yang bersambung kepada rangkaian IP perlu ditala sebelum ia mampu berhubungan dengan komputer lain di rangkaian. DHCP membenarkan komputer ditala secara automatik, menyingkirkan keperluan campur tangan oleh pantakbir rangkaian. Ia turut membekalkan pangkalan data pusat bangi menjejak komputer yang telah bersambung kepada rangkaian. Ini menghalang komputer daripada secara tidak sengaja ditala dengan alamat IP yang sama.
Dengan ketiadaan DHCP, hos boleh ditala secara manual dengan alamat IP. Pilihan lain hos IPv6 mungkin menggunakan autokonfigurasi tanpa alamat bagi menghasilkan alamat IP. Hos IPv4 boleh menggunakan pengalamatan sambungan tempatan bagi mencapai penyambungan tempatan terhad.
Tambahan kepada alamat IP, DHCP turut memberikan maklumat tatarajah lain, terutama alamat IP bagi pelerai DNS pengagregatan tempatan. Hos yang tidak menggunakan DHCP bagi tatarajah alamat masih mingkin menggunakannya bagi mendapatkan maklumat tatarajah yang lain.
Terdapat dua versi DHCP, satu bagi IPv4 dan satu lagi bagi IPv6. Sungguhpun kedua versi memiliki nama yang sama dan melaksanakan tujuan yang sama, perincian bagi protokol bagi IPv4 dan IPv6 adalah cukup berbeza sehinggakan ia bileh dianggap protokol berbeza.[2]
Sejarah
[sunting | sunting sumber]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.[3]
Perincian teknikal
[sunting | sunting sumber]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.
Jumpaan DHCP
[sunting | sunting sumber]Pelanggan memancarkan perutusan pada subrangkaian fizikal bagi mendapatkan pelayan DHCP yang ada. pentadbir rangkaian boleh menatarajaj penghala tempatan untuk menghantar paket DHCP ke pelayan DHCP daripada subrangkaian berbeza. Perlaksanaan pelanggan ini mencipta paket Protokol Datagram Pengguna ("[[User Datagram Protocol-UDP") dengan matlamat pemancar 255.255.255.255 atau alamat pemancar subrangkaian khusus.
Pelanggan DHCP juga boleh meminta alamat IP terakhir yang diketahui (dalam contoh di bawah, 192.168.1.100). Jika pelanggan kekal bersambung pada rangkaian bagi mana IP ini sah, pelayan mungkin meluluskan permohonan. Sekiranya tidak, ia bergantung samaada pelayan didirikan sebagai berwibawa atau tidak. Pelayan berwibawa akan menafikan permohonan, memaksa pelanggan memohon alamat IP baru serta merta. Pelawan tidak berwibawa hanya tidak mengendahkan permohonan, mendorong kepada perlaksanaan bergantung kepada masa luput bagi pelanggan untuk berputus asa bagi permohonan dan memohon alamat IP yang baru.
| UDP Src=0.0.0.0 sPort=68 Dest=255.255.255.255 dPort=67 | |||
| OP | HTYPE | HLEN | HOPS |
|---|---|---|---|
| 0x01 | 0x01 | 0x06 | 0x00 |
| XID | |||
| 0x3903F326 | |||
| SECS | FLAGS | ||
| 0x0000 | 0x0000 | ||
| CIADDR | |||
| 0x00000000 | |||
| YIADDR | |||
| 0x00000000 | |||
| SIADDR | |||
| 0x00000000 | |||
| GIADDR | |||
| 0x00000000 | |||
| CHADDR | |||
| 0x00053C04 | |||
| 0x8D590000 | |||
| 0x00000000 | |||
| 0x00000000 | |||
| 192 octets of 0's. BOOTP legacy | |||
| Magic Cookie | |||
| 0x63825363 | |||
| DHCP Options | |||
| DHCP option 53: DHCP Discover | |||
| DHCP option 50: 192.168.1.100 requested | |||
| DHCP option 55: Parameter Request List:
Request Subnet Mask (1), Router (3), Domain Name (15), Domain Name Server (6) | |||
Twaran DHCP
[sunting | sunting sumber]Apabila pelayan DHCP menerima permohonan sewa IP daripada pelanggan, ia menyimpan satu alamat IP bagi pelanggan dan menghantar tawaran sewa IP dengan menghantar perutusan DHCPOFFER kepada pelanggan. Perutusan ini mengandungi alamat MAC pelanggan, alamat IP yang ditawarkan hos, topeng subrangkaian, tempoh sewa, dan alamat IP bagi pelayan DHCP yang membuat tawaran.
Pelayan menentukan tatarajah bergantung kepada alamat pelanggan sebagaimana ditetapkan dalam bidang CHADDR (Client Hardware Address). Di sini pelayan, 192.168.1.1, menetapkan alamat IP dalam bidang YIADDR (Your IP Address).
| UDP Src=192.168.1.1 sPort=67 Dest=255.255.255.255 dPort=68 | ||||
| OP | HTYPE | HLEN | HOPS | |
|---|---|---|---|---|
| 0x02 | 0x01 | 0x06 | 0x00 | |
| XID | ||||
| 0x3903F326 | ||||
| SECS | FLAGS | |||
| 0x0000 | 0x0000 | |||
| CIADDR | ||||
| 0x00000000 | ||||
| YIADDR | ||||
| 0xC0A80164 | ||||
| SIADDR | ||||
| 0xC0A80101 | ||||
| GIADDR | ||||
| 0x00000000 | ||||
| CHADDR | ||||
| 0x00053C04 | ||||
| 0x8D590000 | ||||
| 0x00000000 | ||||
| 0x00000000 | ||||
| 192 octets of 0's. BOOTP legacy | ||||
| Magic Cookie | ||||
| 0x63825363 | ||||
| DHCP Options | ||||
| DHCP option 53: DHCP Offer | ||||
| DHCP option 1: 255.255.255.0 subnet mask | ||||
| DHCP option 3: 192.168.1.1 router | ||||
| DHCP option 51: 86400s (1 day) IP lease time | ||||
| DHCP option 54: 192.168.1.1 DHCP server | ||||
| DHCP option 6: DNS servers 9.7.10.15, 9.7.10.16, 9.7.10.18 | ||||
Permohonan DHCP
[sunting | sunting sumber]Pelanggan boleh menerima tawaran DHCP daripada beberapa pelayan, tetapi hanya menerima hanya satu tawaran DHCP dan memancarkan perutusan permohonan DHCP. Berdasarkan bidang Transaction ID dalam permohonan, pelayan diberitahu tawaran siapa yang diterima pelanggan. Apabila pelayan DHCP lain menerima perutusan ini, mereka menarik kembali sebarang tawaran yang diberikan kepada pelanggan dan memulangkan alamat yang ditawarkan kembali kepada kelompok alamat yang tersedia. Perutusan permohonan DHCP dipancarkan, dan bukannya dipancar khusus kepada pelayan DHCP tertentu, kerana pelanggan DHCP masih belum menerima alamat IP. Juga, perutusan satu hala boleh memberitahu pelayan DHCP lain untuk memberitahu bahawa pelayan lain akan membekalkan alamat IP tanpa tertinggal sebarang pelayan sekiranya menggunakan perutusan pemancar tunggal.
| UDP Src=0.0.0.0 sPort=68 Dest=255.255.255.255 dPort=67 | ||||
| OP | HTYPE | HLEN | HOPS | |
|---|---|---|---|---|
| 0x01 | 0x01 | 0x06 | 0x00 | |
| XID | ||||
| 0x3903F326 | ||||
| SECS | FLAGS | |||
| 0x0000 | 0x0000 | |||
| CIADDR | ||||
| 0x00000000 | ||||
| YIADDR | ||||
| 0xC0A80164 | ||||
| SIADDR | ||||
| 0xC0A80101 | ||||
| GIADDR | ||||
| 0x00000000 | ||||
| CHADDR | ||||
| 0x00053C04 | ||||
| 0x8D590000 | ||||
| 0x00000000 | ||||
| 0x00000000 | ||||
| 192 octets of 0's. BOOTP legacy | ||||
| Magic Cookie | ||||
| 0x63825363 | ||||
| DHCP Options | ||||
| DHCP option 53: DHCP Request | ||||
| DHCP option 50: 192.168.1.100 requested | ||||
| DHCP option 54: 192.168.1.1 DHCP server. | ||||
Akuan DHCP
[sunting | sunting sumber]Apabila pelayan DHCP menerima perutusan DHCPREQUEST daripada pelanggan, proses tatarajah memasuki fasa terakhirnya. Fasa akuan membabitkan menghantar paket DHCPACK kepada pelanggan. paket ini termasuk tempoh sewaan dan sebarang maklumat tatarajah lain yang mungkin diminta pelanggan. pada ketika ini, proses tatarajah IP dilengkapkan.
Protokol menjangka pelanggan DHCP untuk menatarajah antaramuka rangkaiannya dengan parameter yang dirundingkan.
| UDP Src=192.168.1.1 sPort=67 Dest=255.255.255.255 dPort=68 | ||||
| OP | HTYPE | HLEN | HOPS | |
|---|---|---|---|---|
| 0x02 | 0x01 | 0x06 | 0x00 | |
| XID | ||||
| 0x3903F326 | ||||
| SECS | FLAGS | |||
| 0x0000 | 0x0000 | |||
| CIADDR (Client IP Address) | ||||
| 0x00000000 | ||||
| YIADDR (Your IP Address) | ||||
| 0xC0A80164 | ||||
| SIADDR (Server IP Address) | ||||
| 0xC0A80101 | ||||
| GIADDR (Gateway IP Address switched by relay) | ||||
| 0x00000000 | ||||
| CHADDR (Client Hardware Address) | ||||
| 0x00053C04 | ||||
| 0x8D590000 | ||||
| 0x00000000 | ||||
| 0x00000000 | ||||
| 192 octets of 0's. BOOTP legacy | ||||
| Magic Cookie | ||||
| 0x63825363 | ||||
| DHCP Options | ||||
| DHCP option 53: DHCP ACK | ||||
| DHCP option 1: 255.255.255.0 subnet mask | ||||
| DHCP option 3: 192.168.1.1 router | ||||
| DHCP option 51: 86400s (1 day) IP lease time | ||||
| DHCP option 54: 192.168.1.1 DHCP server | ||||
| DHCP option 6: DNS servers 9.7.10.15, 9.7.10.16, 9.7.10.18 | ||||
After the client obtains an IP address, the client may use the Address Resolution Protocol (ARP) to prevent IP conflicts caused by overlapping address pools of DHCP servers.
DHCP information
[sunting | sunting sumber]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
[sunting | sunting sumber]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
[sunting | sunting sumber]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.[4]
Pilihan
[sunting | sunting sumber]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
[sunting | sunting sumber]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
[sunting | sunting sumber]Piwaian bagi melaksanakan reka bentuk tahan rosak pelayan DHCP telah dibincangkan oleh Internet Engineering Task Force,[5] 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.
Keselamatan
[sunting | sunting sumber]Asas protokol DHCP menjadi piwaian sebelum keselamatan rangkaian menjadi isu penting: ia termasuk tidak memiliki ciri-ciri keselamatan, ia berpontensi lemah kepada dua jenis serangan:[6]
- Pelayan DHCP Tidak Sah : kerana anda tidak dapat menetapkan pelayan yang anda mahu, pelayan tidak sah mampu membalas permohonan pelanggan, menghantar tatarajah pelanggan yang menguntungkan penyerang. Sebagai contoh, hacker boleh merampas proses DHCP untuk menatarajah pelanggan untuk menggunakan sistem nama Domain jahat atau penghala (lihat juga Keracunan cache DNS).
- Pelanggan DHCP Tidak sah: Dengan menyamar sebagai pelanggan sah, pelanggan tidak sah boleh mendapatkan capaian kepada tatarajah rangkaian dan alamat IP pada rangkaian yang sepatutnya ia tidak dibenarkan menggunakannya. Juga, dengan melempahkan pelayan DHCP dengan permohonan alamat IP, ia adalah mungkin bagi penyerang untuk menghabiskan kumpulan alamat IP yang tersedia, mengganggu aktiviti normal rangkian (satu serangan penafian perkhidmatan).
Bagi menentang ancaman ini RFC 3118 ("Authentication for DHCP Messages") memperkenalkan maklumat pengesahan ke dalam perutusan DHCP, membenarkan pelayan dan pelanggan untuk menolak maklumat daripada sumber tidak sah. Sungguhpun sokongan bagi protokol ini meluas, sejumlah besar pelayan dan pelanggan masih tidak menyokong pengesahan sepenuhnya, dengan itu memaksa pelayan bagi menyokong pelanggan yang tidak menyokong ciri ini. Hasilnya, langkah keselamatan lain biasanya dilaksanakan sekitar pelayan DHCP (seperti IPsec) bagi memastikan hanya pelanggan dan pelayan sah diberikan capaian kepada rangkaian.
Alamat perlu dikaitkan secara dinamik kepada pelayan DNS selamat, untuk membolehkan penyelesaian masalah menggunakan nama dan bukannya dengan potensi alamat yang tidak dikenali Sambungan DHCP-DNS berkesan perlu memiliki fail samaada alamat MAC atau nama-nama tempatan yang akan dihantar ke DNS yang unik untuk mengenalpasti host fizikal, alamat IP, dan parameter lain seperti get lalai, topeng subjaring, dan alamat IP dari pelayan sistem nama Domain DNS dari pelayan DHCP. Pelayan DHCP menjamin bahawa semua alamat IP adalah unik, iaitu, tidak ada alamat IP diberikan kepada pelanggan kedua sedangkan tugasan pelanggan pertama masih sah (sewanya belum luput). Dengan itu pengurusan himpunan alamat IP dilakukan oleh pelayan dan tidak oleh pentadbir rangkaian.
Rujukan
[sunting | sunting sumber]- ^ Dewan Bahasa dan Pustaka.
- ^ Ralph Droms; Ted Lemon (2003). The DHCP Handbook. SAMS Publishing. m/s. 436. ISBN 0-672-32327-3.
- ^ Bill Croft; John Gilmore (September 1985). "RFC 951 - Bootstrap Protocol". Network Working Group.
- ^ In Unix-like systems this client-level refinement typically takes place according to the values in a
/etc/dhclient.confconfiguration file. - ^ Droms, Ralph; Kinnear, Kim; Stapp, Mark; Volz, Bernie; Gonczi, Steve; Rabil, Greg; Dooley, Michael; Kapur, Arun (2003). DHCP Failover Protocol. IETF. I-D draft-ietf-dhc-failover-12. Dicapai pada May 09, 2010. Unknown parameter
|month=ignored (bantuan); Check date values in:|accessdate=(bantuan) - ^ The TCP/IP Guide - Security Issues
Pautan luar
[sunting | sunting sumber]- RFC 2131 - Dynamic Host Configuration Protocol
- RFC 2132 - DHCP Options and BOOTP Vendor Extensions
- DHCP RFC Diarkibkan 2006-08-15 di Wayback Machine - Dynamic Host Configuration Protocol RFCs (IETF)
- RFC 4242 - Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6
- DHCP Sequence Diagram Diarkibkan 2010-03-31 di Wayback Machine - This sequence diagram covers several scenarios of DHCP operation.
- RFC 3046, Recommended Operation for Switches Running Relay Agent and Option 82 Diarkibkan 2008-12-30 di Wayback Machine describes how DHCP option 82 works
- RFC 3942 - Reclassifying Dynamic Host Configuration Protocol Version Four (DHCPv4) Options
- RFC 4361 - Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) A good description of the individual DHCP protocol messages.
- DHCP Protocol Messages - A good description of the individual DHCP protocol messages.
- ISC DHCP - Internet Services Consortium's open source DHCP implementation.
- Dynamic Host Configuration Protocol (DHCP) - Microsoft TechNet