1. Pendahuluan
Dynamic Host Configuration Protocol (DHCP) menyediakan konfigurasi
parameter ke Internet host. DHCP terdiri dari dua komponen: sebuah
protokol untuk menyampaikan host-parameter konfigurasi tertentu dari
DHCP server ke host dan sebuah mekanisme untuk alokasi jaringan
alamat untuk host.
DHCP dibangun pada model client-server, dimana DHCP server ditentukan
host mengalokasikan alamat jaringan dan memberikan parameter konfigurasi
host dikonfigurasi untuk secara dinamis. Seluruh sisa dari
dokumen, istilah "server" mengacu ke host menyediakan initialization
parameter melalui DHCP, dan istilah "klien" mengacu ke host
meminta initialization parameter dari server DHCP.
Sebuah host tidak boleh bertindak sebagai server DHCP yang dikonfigurasi secara eksplisit kecuali
untuk melakukannya oleh administrator sistem. Keragaman hardware dan
protokol implementasi di Internet akan menghalangi diandalkan
operasi jika tuan rumah acak diizinkan untuk merespon permintaan DHCP.
Sebagai contoh, IP membutuhkan pengaturan dari banyak parameter dalam
implementasi protokol perangkat lunak. Karena IP dapat digunakan pada banyak
berbeda jenis perangkat keras jaringan, nilai untuk parameter tersebut
tidak dapat ditebak atau dianggap telah benar default. Juga,
skema alokasi alamat dibagikan tergantung pada polling / pertahananmekanisme untuk penemuan alamat yang sudah digunakan. IP
host mungkin tidak selalu dapat mempertahankan alamat jaringan mereka, sehingga
bahwa seperti skema alokasi alamat didistribusikan tidak dapat
dijamin untuk menghindari duplikasi alokasi alamat jaringan.
DHCP mendukung tiga mekanisme untuk alokasi alamat IP. Di
"alokasi otomatis", DHCP memberikan alamat IP permanen ke
klien. Dalam "alokasi dinamis", DHCP memberikan alamat IP ke
klien untuk jangka waktu terbatas (atau sampai klien secara eksplisit
relinquishes alamat). Dalam "alokasi manual", sebuah klien IP
alamat yang diberikan oleh administrator jaringan, dan DHCP digunakan
hanya untuk menyampaikan alamat yang ditugaskan ke klien. A khusus
jaringan akan menggunakan satu atau lebih dari mekanisme ini, tergantung pada
kebijakan dari administrator jaringan.
Dynamic alokasi adalah hanya salah satu dari tiga mekanisme yang
memungkinkan penggunaan kembali otomatis alamat yang tidak lagi dibutuhkan oleh
klien yang ditugaskan. Dengan demikian, alokasi dinamis
terutama berguna untuk menetapkan sebuah alamat kepada klien yang akan
terhubung ke jaringan hanya sementara atau untuk berbagi terbatas
renang alamat IP di antara sekelompok klien yang tidak memerlukan
alamat IP permanen. Alokasi dinamis mungkin juga menjadi pilihan yang baik
untuk menetapkan alamat IP untuk klien baru yang permanen
terhubung ke jaringan di mana alamat IP yang cukup langka
bahwa penting untuk merebut kembali mereka ketika klien lama pensiun.
Memungkinkan alokasi manual DHCP digunakan untuk menghilangkan kesalahan-rawan
proses secara manual mengkonfigurasi host dengan alamat IP dalam
lingkungan di mana (untuk alasan apapun) itu diinginkan untuk mengelola
Alamat IP di luar mekanisme DHCP.
Format pesan DHCP didasarkan pada format pesan BOOTP,
untuk menangkap perilaku agen relai BOOTP digambarkan sebagai bagian dari
BOOTP spesifikasi [7, 21] dan untuk memungkinkan interoperabilitas yang ada
BOOTP klien dengan server DHCP. Menggunakan agen relai BOOTP menghilangkan
perlunya memiliki sebuah server DHCP pada jaringan fisik masing-masing
segmen.
Perubahan 1,1 RFC 1541
Dokumen ini pembaruan protokol DHCP spesifikasi yang muncul di
RFC1541. Sebuah jenis pesan DHCP baru, DHCPINFORM, telah ditambahkan; lihat
bagian 3.4, 4.3 dan 4.4 untuk rincian. Mekanisme yang mengklasifikasikan
mengidentifikasi klien DHCP server DHCP telah diperluas untuk mencakup
"vendor" kelas sebagaimana didefinisikan dalam bagian 4.2 dan 4.3. Minimum
lease time pembatasan telah dihapus. Akhirnya, banyak editorial
perubahan yang telah dibuat untuk memperjelas teks sebagai hasil dari pengalaman
diperoleh dalam tes interoperabilitas DHCP.
1,2 Terkait Kerja
Ada beberapa Internet protokol dan mekanisme yang terkait
alamat beberapa bagian konfigurasi host dinamik masalah. Itu
Reverse Address Resolution Protocol (RARP) [10] (melalui
ekstensi didefinisikan dalam Dynamic RARP (DRARP) [5]) secara eksplisit
masalah alamat alamat jaringan penemuan, dan mencakup
alamat IP otomatis mekanisme. The Trivial File Transfer
Protokol (TFTP) [20] menyediakan transportasi dari boot image dari
boot server. Internet Control Message Protocol (ICMP) [16]
menyediakan host untuk menginformasikan router tambahan melalui "ICMP
redirect "pesan. ICMP juga dapat memberikan informasi subnet mask
melalui "topeng ICMP permintaan" pesan dan informasi lainnya melalui
yang (obsolete) "permintaan informasi ICMP" pesan. Host dapat menemukan
ICMP router melalui mekanisme penemuan router [8].
BOOTP adalah mekanisme transportasi untuk koleksi konfigurasi
informasi. BOOTP juga extensible, dan ekstensi resmi [17]
telah ditetapkan untuk beberapa parameter konfigurasi. Morgan
diusulkan ekstensi untuk BOOTP untuk alamat IP dinamis tugas [15].
Network Information Protocol (NIP), yang digunakan oleh proyek Athena
MIT, adalah sebuah mekanisme untuk didistribusikan alamat IP dinamis
[19]. Resource Location Protocol RLP [1] menyediakan lokasi
layanan tingkat tinggi. Sun Microsystems workstation diskless menggunakan
prosedur boot yang mempekerjakan RARP, TFTP dan mekanisme yang disebut RPC
"bootparams" untuk menyampaikan informasi konfigurasi dan operasi
kode untuk sistem diskless host. (Sun Microsystems, Sun Workstation
dan SunOS adalah merek dagang dari Sun Microsystems, Inc) Beberapa Minggu
jaringan juga menggunakan DRARP dan instalasi otomatis mekanisme untuk
mengotomatisasi konfigurasi host baru di jaringan yang sudah ada.
Dalam kerja terkait lainnya, jalan minimal transmission unit (MTU)
penemuan algoritma dapat menentukan MTU dari internet yang sewenang-wenang
path [14]. The Address Resolution Protocol (ARP) telah diusulkan
sebagai protokol transport untuk lokasi dan seleksi sumber daya [6].
Akhirnya, Host Persyaratan RFC [3, 4] menyebutkan spesifik
persyaratan untuk host konfigurasi ulang dan menyarankan skenario untuk
konfigurasi awal diskless host.
Soal 1,3 definisi dan isu-isu
DHCP ini didesain untuk menyediakan klien DHCP dengan konfigurasi
parameter yang didefinisikan dalam RFC Persyaratan Host. Setelah mendapat
parameter melalui DHCP, sebuah klien DHCP harus mampu pertukaran paket
dengan host lain di internet. TCP / IP stack parameter
diberikan oleh DHCP tercantum dalam Lampiran A.
Tidak semua parameter yang diperlukan untuk baru diinisialisasi
klien. Seorang klien dan server dapat bernegosiasi untuk transmisi
hanya orang-parameter yang diperlukan oleh klien atau spesifik untuk sebuah
subnet tertentu.
DHCP memungkinkan tetapi tidak memerlukan konfigurasi klien
parameter tidak terkait langsung dengan protokol IP. DHCP juga tidak
alamat pendaftaran tidak dikonfigurasi baru klien dengan Domain
Name System (DNS) [12, 13].
DHCP tidak dimaksudkan untuk digunakan dalam mengkonfigurasi router.
1,4 Persyaratan
Sepanjang dokumen ini, kata-kata yang digunakan untuk mendefinisikan
signifikansi persyaratan tertentu dikapitalisasi. Kata-kata
adalah:
o "HARUS"
Kata ini atau kata sifat "REQUIRED" berarti bahwa
item adalah kebutuhan mutlak spesifikasi ini.
o "TIDAK HARUS"
Ungkapan ini berarti bahwa item larangan mutlak
spesifikasi ini.
o "HARUS"
Kata ini atau kata sifat "RECOMMENDED" berarti bahwa ada
mungkin ada alasan yang sah dalam keadaan tertentu untuk mengabaikan
item ini, tetapi implikasi penuh harus dipahami dan
kasus ditimbang dengan seksama sebelum memilih kursus yang berbeda.
o "TIDAK BOLEH"
Ungkapan ini berarti bahwa mungkin ada alasan yang sah dalam
keadaan tertentu ketika perilaku yang terdaftar dapat diterima
atau bahkan berguna, tetapi implikasi penuh harus dipahami
dan kasus ditimbang dengan hati-hati sebelum menerapkan semua perilaku
dijelaskan dengan label ini.
o "MUNGKIN"
Kata ini atau kata sifat "OPTIONAL" berarti bahwa item ini
benar-benar opsional. Satu vendor dapat memilih untuk menyertakan item
karena membutuhkan pasar tertentu atau karena
meningkatkan produk, misalnya; vendor lain dapat menghilangkan
item yang sama.
1,5 Terminologi
Dokumen ini menggunakan istilah-istilah berikut:
o "klien DHCP"
Seorang klien DHCP adalah host internet menggunakan DHCP untuk mendapatkan
parameter konfigurasi seperti alamat jaringan.
o "server DHCP"
Sebuah server DHCP adalah host Internet yang mengembalikan konfigurasi
parameter untuk klien DHCP.
o "agen relai BOOTP"
Sebuah BOOTP relay agent atau agen relay adalah host atau router Internet
yang melewati DHCP DHCP pesan antara klien dan server DHCP.
DHCP ini dirancang untuk menggunakan agen relay yang sama perilaku sebagaimana ditentukan
dalam protokol BOOTP spesifikasi.
o "mengikat"
Yang mengikat adalah kumpulan parameter konfigurasi, termasuk
paling tidak sebuah alamat IP, yang berhubungan dengan atau "terikat" DHCP
klien. Bindings dikelola oleh server DHCP.
Desain 1,6 gol
Daftar berikut memberikan tujuan desain umum untuk DHCP.
o DHCP harus menjadi mekanisme, bukan kebijakan. DHCP harus
memungkinkan administrator sistem lokal konfigurasi kontrol
parameter mana yang dikehendaki; misalnya, administrator sistem lokal
harus mampu menerapkan kebijakan lokal mengenai alokasi
dan akses ke sumber daya lokal di mana yang diinginkan.
o Klien seharusnya tidak memerlukan konfigurasi manual. Setiap klien
harus dapat menemukan konfigurasi lokal sesuai
parameter tanpa campur tangan pengguna dan memasukkan orang
parameter ke dalam konfigurasi sendiri.
o Jaringan seharusnya tidak memerlukan konfigurasi manual untuk setiap
klien. Dalam keadaan normal, manajer jaringan
seharusnya tidak perlu memasukkan konfigurasi per-klien
parameter.
o DHCP seharusnya tidak memerlukan server pada setiap subnet. Untuk memungkinkan
skala dan ekonomi, DHCP harus bekerja di router atau melalui
intervensi dari agen relai BOOTP.
o klien DHCP harus siap untuk menerima banyak tanggapan
untuk permintaan untuk konfigurasi parameter. Beberapa instalasi
mungkin mencakup beberapa, tumpang tindih server DHCP untuk meningkatkan
kehandalan dan meningkatkan kinerja.
o DHCP harus hidup berdampingan dengan statis dikonfigurasi, non-berpartisipasi
host dan dengan implementasi protokol jaringan yang ada.
o DHCP harus beroperasi dengan agen relai BOOTP perilaku sebagai
digambarkan oleh RFC 951 dan RFC 1542 [21].
o DHCP harus memberikan layanan kepada klien BOOTP yang ada.
Daftar berikut memberikan tujuan desain khusus untuk transmisi
parameter lapisan jaringan. DHCP harus:
o Jaminan bahwa alamat jaringan tertentu tidak akan di
digunakan oleh lebih dari satu klien DHCP pada satu waktu,
o Simpan konfigurasi klien DHCP klien DHCP di reboot. Sebuah
Klien DHCP harus, jika memungkinkan, akan ditugaskan sama
parameter konfigurasi (misalnya, alamat jaringan) sebagai tanggapan
untuk setiap permintaan,
o Simpan konfigurasi klien DHCP server di reboot, dan,
bila mungkin, sebuah klien DHCP harus diserahkan sama
meskipun parameter konfigurasi DHCP restart dari mekanisme,
o Biarkan penugasan otomatis parameter konfigurasi baru
tangan klien untuk menghindari konfigurasi untuk klien baru,
o Dukungan tetap atau permanen konfigurasi alokasi
parameter untuk klien tertentu.
2. Ringkasan Protokol
Dari klien sudut pandang, DHCP adalah perpanjangan dari BOOTP
mekanisme. Perilaku ini memungkinkan klien BOOTP yang ada untuk
beroperasi dengan DHCP server tanpa memerlukan perubahan ke
klien 'inisialisasi perangkat lunak. RFC 1542 [2] merinci
interaksi antara BOOTP dan DHCP klien dan server [9]. Ada
adalah beberapa yang baru, pilihan transaksi yang mengoptimalkan interaksi
antara klien dan server DHCP yang dijelaskan dalam bagian 3 dan
4.
Gambar 1 memberikan format pesan DHCP dan tabel 1 menggambarkan
masing-masing kolom-kolom pada pesan DHCP. Angka-angka dalam tanda kurung
mengindikasikan ukuran setiap field dalam oktet. Nama-nama untuk bidang
diberikan pada gambar akan digunakan di seluruh dokumen ini untuk merujuk
kolom-kolom pada pesan DHCP.
Ada dua perbedaan utama antara DHCP dan BOOTP. Pertama,
DHCP mendefinisikan mekanisme klien yang dapat diberi
alamat jaringan untuk sewa yang terbatas, sehingga memungkinkan untuk serial penugasan kembali
alamat jaringan klien yang berbeda. Kedua, DHCP menyediakan
mekanisme untuk klien untuk mendapatkan semua konfigurasi IP
parameter yang diperlukan dalam rangka untuk beroperasi.
DHCP memperkenalkan perubahan kecil dalam terminologi dimaksudkan untuk memperjelas
arti dari salah satu bidang. Apa adalah "penjual ekstensi" lapangan
di BOOTP telah kembali dinamakan "pilihan" di bidang DHCP. Demikian pula,
item data pengajuan yang digunakan di dalam BOOTP "vendor
ekstensi "lapangan, yang sebelumnya disebut sebagai" vendor
ekstensi, "sekarang disebut hanya" pilihan. "
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+
| Op (1) | htype (1) | hlen (1) | hop (1) |
+---------------+---------------+---------------+- --------------+
| Xid (4) |
+-------------------------------+----------------- --------------+
| Secs (2) | flag (2) |
+-------------------------------+----------------- --------------+
| Ciaddr (4) |
+------------------------------------------------- --------------+
| Yiaddr (4) |
+------------------------------------------------- --------------+
| Siaddr (4) |
+------------------------------------------------- --------------+
| Giaddr (4) |
+------------------------------------------------- --------------+
| |
| Chaddr (16) |
| |
| |
+------------------------------------------------- --------------+
| |
| Sname (64) |
+------------------------------------------------- --------------+
| |
| File (128) |
+------------------------------------------------- --------------+
| |
| Pilihan (variabel) |
+------------------------------------------------- --------------+
Gambar 1: Format pesan DHCP
DHCP mendefinisikan 'baru klien identifier' pilihan yang digunakan untuk lulus
eksplisit pengenal klien server DHCP. Perubahan ini menghilangkan
yang overloading dari 'chaddr' bidang dalam pesan BOOTP, dimana
'chaddr' digunakan baik sebagai alamat hardware untuk transmisi BOOTP
membalas pesan dan sebagai pengenal klien. The 'klien identifier'
adalah kunci opaque, tidak harus ditafsirkan oleh server, misalnya,
the 'klien identifier' mungkin berisi alamat hardware, identik dengan
isi 'chaddr' lapangan, atau mungkin berisi jenis lain
identifier, seperti nama DNS. The 'klien identifier' dipilih oleh seorang
HARUS klien DHCP yang unik untuk klien di dalam subnet yang
klien terpasang. Jika klien menggunakan 'klien identifier' dalam
satu pesan, itu harus menggunakan identifier yang sama dalam semua berikutnya
pesan, untuk memastikan bahwa semua server dengan benar mengidentifikasi klien.
DHCP menjelaskan interpretasi dari 'siaddr' bidang sebagai
alamat server untuk digunakan pada langkah berikutnya dari klien
proses bootstrap. Sebuah server DHCP dapat kembali alamat sendiri dalam
'siaddr' lapangan, jika server siap untuk memasok berikutnya
bootstrap layanan (misalnya, pengiriman sistem operasi dieksekusi
gambar). Sebuah server DHCP selalu kembali alamat sendiri dalam 'server
identifier 'pilihan.
Octets FIELD DESCRIPTION
----- ------ -----------
Pesan op pada 1 kode / jenis pesan.
1 = BOOTREQUEST, 2 = BOOTREPLY
htype 1 Tipe alamat hardware, lihat bagian ARP dalam "Assigned
Bilangan "RFC; e.g., '1 '= 10mb ethernet.
Hardware 1 alamat hlen panjang (mis. '6 'untuk 10mb
ethernet).
Klien 1 hop set ke nol, secara opsional digunakan oleh agen relay
ketika booting melalui agen relai.
xid 4 Transaksi ID, nomor acak yang dipilih oleh
klien, yang digunakan oleh klien dan server untuk menghubungkan
pesan dan tanggapan antara klien dan
server.
secs 2 Diisi oleh klien, detik berlalu sejak klien
alamat mulai proses perolehan atau pembaharuan.
flags 2 Flags (lihat gambar 2).
ciaddr 4 Client alamat IP, hanya diisi jika klien dalam
TERIKAT, REBINDING memperbarui atau negara dan dapat merespon
untuk ARP permintaan.
yiaddr 4 'Anda' (klien) alamat IP.
siaddr 4 alamat IP server berikutnya untuk digunakan dalam bootstrap;
kembali dalam DHCPOFFER, DHCPACK oleh server.
4 Relay giaddr agen alamat IP, digunakan dalam booting melalui
relay agen.
16 Klien chaddr alamat hardware.
64 sname nama host server opsional, nol mengakhiri string.
128 file Boot nama file, null dihentikan string; "generik"
nama atau null di DHCPDISCOVER, sepenuhnya memenuhi syarat
direktori-nama path di DHCPOFFER.
Pilihan var parameter opsional lapangan. Melihat opsi
dokumen untuk daftar pilihan yang ditetapkan.
Tabel 1: Deskripsi fields dalam pesan DHCP
The 'Pilihan' lapangan sekarang variabel panjang. Seorang klien DHCP harus
siap untuk menerima pesan DHCP dengan sebuah 'pilihan' sekurang-kurangnya bidang
panjang 312 oktet. Persyaratan ini menyiratkan bahwa klien DHCP harus
bersiaplah untuk menerima pesan sampai 576 oktet, minimum IP
ukuran datagram IP host harus siap menerima [3]. DHCP
klien dapat menegosiasikan penggunaan DHCP yang lebih besar pesan melalui
'maksimum ukuran pesan DHCP' pilihan. Bidang pilihan mungkin lebih lanjut
diperluas ke 'file' dan 'sname' fields.
Dalam kasus klien menggunakan DHCP untuk konfigurasi awal (sebelum
klien TCP / IP perangkat lunak telah sepenuhnya dikonfigurasi), DHCP
memerlukan penggunaan kreatif klien TCP / IP perangkat lunak dan liberal
interpretasi dari RFC 1122. TCP / IP software HARUS menerima dan
maju ke lapisan IP setiap paket IP dikirim ke klien
alamat hardware sebelum alamat IP dikonfigurasi; DHCP server
dan agen relai BOOTP mungkin tidak dapat memberikan pesan DHCP
klien yang tidak dapat menerima unicast hardware datagrams sebelum
TCP / IP perangkat lunak dikonfigurasi.
Untuk bekerja di sekitar beberapa klien yang tidak dapat menerima IP unicast datagrams
sebelum TCP / IP perangkat lunak dikonfigurasi seperti yang dibahas di sebelumnya
paragraf, DHCP menggunakan 'bendera' field [21]. Bit paling kiri
didefinisikan sebagai PENYIARAN (B) flag. Semantik bendera ini adalah
dibahas dalam bagian 4.1 dari dokumen ini. Bit yang tersisa dari
lapangan bendera dicadangkan untuk penggunaan masa depan. Mereka HARUS diatur ke nol oleh
diabaikan oleh klien dan server dan relay agen. Gambar 2 memberikan
format 'bendera' lapangan.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B: BROADCAST flag
MBZ: HARUS KOSONG (dicadangkan untuk penggunaan di masa depan)
Gambar 2: Format 'bendera' bidang
Konfigurasi parameter 2,1 repositori
Layanan pertama yang disediakan oleh DHCP adalah untuk memberikan persistent storage
parameter jaringan untuk klien jaringan. Model DHCP
persistent storage adalah bahwa layanan DHCP toko nilai kunci entry
untuk setiap klien, di mana kuncinya adalah beberapa identifikasi unik (untuk
contoh, sebuah IP subnet nomor pengenal yang unik dalam
subnet) dan berisi nilai parameter konfigurasi untuk
klien.
Sebagai contoh, mungkin kunci pasangan (IP-subnet-nomor, hardware -
alamat) (catatan bahwa "hardware-address" harus diketik oleh
jenis hardware untuk mengakomodasi kemungkinan duplikasi hardware
alamat yang dihasilkan dari bit-masalah memesan dalam campuran media,
bridge jaringan) memungkinkan untuk serial atau bersamaan penggunaan kembali sebuah
alamat hardware pada subnet yang berbeda, dan untuk alamat hardware
yang mungkin tidak secara global unik. Bergantian, mungkin kunci yang
pasangan (IP-subnet-nomor, nama host), yang memungkinkan server untuk menetapkan
parameter cerdas untuk klien DHCP yang telah dipindahkan ke
subnet yang berbeda atau telah berubah alamat hardware (mungkin karena
antarmuka jaringan gagal dan digantikan). Mendefinisikan protokol
bahwa kunci akan (IP-subnet-nomor, hardware-address), kecuali apabila
persediaan secara eksplisit klien menggunakan sebuah identifier 'klien
identifier 'pilihan. Seorang klien dapat query layanan DHCP untuk
mengambil parameter konfigurasi. Antarmuka klien ke
parameter konfigurasi repositori terdiri dari pesan protokol untuk
parameter konfigurasi permintaan dan tanggapan dari server
membawa parameter konfigurasi.
Dinamis 2,2 alokasi alamat jaringan
Kedua layanan yang disediakan oleh DHCP adalah alokasi sementara atau
jaringan tetap (IP) alamat kepada klien. Mekanisme dasar
dinamis alokasi alamat jaringan sederhana: seorang klien
permintaan penggunaan alamat untuk jangka waktu tertentu. Itu
mekanisme alokasi (kumpulan dari server DHCP) tidak menjamin
untuk mengalokasikan kembali bahwa alamat yang diminta dalam waktu dan upaya untuk
kembali alamat jaringan yang sama setiap kali permintaan klien yang
alamat. Dalam dokumen ini, periode di mana alamat jaringan
dialokasikan kepada klien disebut sebagai "sewa" [11]. Itu
klien dapat memperluas sewa dengan permintaan berikutnya. Klien dapat
mengeluarkan pesan ke alamat melepaskan kembali ke server ketika
klien tidak lagi membutuhkan alamat. Klien dapat meminta
tugas permanen dengan meminta sewa yang tak terbatas. Bahkan ketika
menugaskan "permanen" alamat, server mungkin memilih untuk memberikan
panjang tetapi non-sewa tak terbatas untuk memungkinkan deteksi kenyataan bahwa
klien telah pensiun.
Dalam beberapa lingkungan akan perlu untuk menetapkan kembali jaringan
alamat karena kelelahan yang tersedia alamat. Dalam
lingkungan, mekanisme alokasi akan menggunakan kembali alamat yang
sewa telah berakhir. Server harus menggunakan informasi apapun
tersedia dalam informasi konfigurasi repositori untuk memilih
alamat kembali. Sebagai contoh, server dapat memilih paling
baru-baru ini alamat ditugaskan. Sebagai konsistensi cek, yang mengalokasikan
HARUS menyelidiki server digunakan kembali mengalokasikan alamat sebelum alamat,
misalnya, dengan permintaan echo ICMP, dan klien HARUS menyelidiki
baru menerima alamat, e.g., dengan ARP.
3. The Client-Server Protokol
DHCP menggunakan format pesan BOOTP didefinisikan pada RFC 951 dan diberikan dalam
Tabel 1 dan Gambar 1. The 'op' lapangan dari setiap pesan yang dikirim dari DHCP
klien ke server berisi BOOTREQUEST. BOOTREPLY digunakan dalam
'op' bidang masing-masing DHCP pesan yang dikirim dari server ke klien.
Empat oktet pertama dari 'pilihan' DHCP bidang pesan
berisi (desimal) nilai 99, 130, 83 dan 99, masing-masing (ini
sihir adalah cookie yang sama seperti yang didefinisikan dalam RFC 1497 [17]). Itu
sisa pilihan '' lapangan terdiri dari daftar tagged
parameter yang disebut "pilihan". Semua "vendor ekstensi"
tercantum dalam RFC 1497 juga pilihan DHCP. RFC 1533 memberikan
lengkap pilihan yang ditetapkan untuk digunakan dengan DHCP.
Beberapa pilihan telah didefinisikan sejauh ini. Satu pilihan tertentu --
yang "jenis pesan DHCP" pilihan - harus disertakan dalam setiap DHCP
pesan. Opsi ini mendefinisikan "type" dari pesan DHCP.
Opsi tambahan mungkin diperbolehkan, diperlukan, atau tidak diperbolehkan,
tergantung pada jenis pesan DHCP.
Sepanjang dokumen ini, DHCP pesan yang mencakup 'pesan DHCP
ketik 'opsi akan disebut oleh jenis pesan, misalnya, seorang
Pesan DHCP dengan 'jenis pesan DHCP' pilihan tipe 1 akan disebut
sebagai "DHCPDISCOVER" pesan.
Klien-server 3,1 interaksi - mengalokasikan alamat jaringan
Ringkasan berikut protokol pertukaran antara klien dan
server mengacu pada pesan DHCP yang dijelaskan pada tabel 2. Itu
timeline diagram pada Gambar 3 menunjukkan hubungan waktu dalam sebuah
khas interaksi client-server. Jika klien sudah tahu dengan
alamat, beberapa langkah yang dapat dihilangkan; ini interaksi disingkat
dijelaskan dalam bagian 3.2.
1. Klien menyiarkan pesan DHCPDISCOVER pada fisik lokal
subnet. Pesan yang MUNGKIN DHCPDISCOVER termasuk pilihan yang menyarankan
nilai untuk alamat jaringan dan sewa durasi. BOOTP relay
agen dapat menyampaikan pesan pada server DHCP tidak sama
subnet fisik.
2. Setiap server akan merespons dengan pesan yang DHCPOFFER mencakup
alamat jaringan yang tersedia di 'yiaddr' lapangan (dan lainnya
konfigurasi DHCP parameter dalam opsi). Server tidak perlu
cadangan alamat jaringan yang ditawarkan, meskipun protokol akan
bekerja lebih efisien jika server mengalokasikan menghindari ditawarkan
alamat jaringan klien lain. Ketika mengalokasikan sebuah alamat baru,
HARUS server periksa apakah alamat jaringan yang ditawarkan tidak
telah digunakan, misalnya, server mungkin probe alamat yang ditawarkan
dengan ICMP Echo Request. Server HARUS dilaksanakan sehingga
MUNGKIN administrator jaringan memilih untuk menonaktifkan probe yang baru
dialokasikan alamat. Server mentransmisikan pesan DHCPOFFER
kepada klien, dengan menggunakan agen relai BOOTP jika perlu.
Pesan Gunakan
------- ---
DHCPDISCOVER - Klien broadcast untuk menemukan server yang tersedia.
DHCPOFFER - Server ke klien dalam menanggapi DHCPDISCOVER dengan
tawaran parameter konfigurasi.
DHCPREQUEST - Klien pesan ke server baik (a) meminta
ditawarkan parameter dari satu server dan secara implisit
menurun menawarkan dari semua orang lain, (b) membenarkan
kebenaran alamat yang dialokasikan sebelumnya setelah,
misalnya, sistem reboot, atau (c) memperpanjang sewa pada
alamat jaringan tertentu.
DHCPACK - Server ke klien dengan parameter konfigurasi,
berkomitmen termasuk alamat jaringan.
DHCPNAK - Server ke klien klien menunjukkan pengertian jaringan
alamat tidak benar (misalnya, klien telah pindah ke baru
subnet) atau klien sewa sebagai kadaluarsa
DHCPDECLINE - Client untuk server menunjukkan alamat jaringan sudah
digunakan.
DHCPRELEASE - Client untuk server jaringan melepaskan alamat dan
membatalkan sisa sewa.
DHCPINFORM - Klien ke server, meminta hanya untuk konfigurasi lokal
parameter; klien sudah memiliki eksternal dikonfigurasi
alamat jaringan.
Tabel 2: DHCP pesan
Server Client Server
(tidak dipilih) (dipilih)
v v v
| | |
| Begins initialization |
| | |
| _____________/| \ ____________ |
| / DHCPDISCOVER | DHCPDISCOVER \ |
| | |
Menentukan | Menentukan
konfigurasi | konfigurasi
| | |
| \ | ____________/ |
| \ ________ | / DHCPOFFER |
| DHCPOFFER \ | / |
| \ | |
| Mengumpulkan balasan |
| \ | |
| Memilih konfigurasi |
| | |
| _____________/| \ ____________ |
| / DHCPREQUEST | DHCPREQUEST \ |
| | |
| | Melakukan konfigurasi
| | |
| | _____________/|
| | / DHCPACK |
| | |
| Inisialisasi lengkap |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| | \ ____________ |
| | DHCPRELEASE \ |
| | |
| | Membuang sewa
| | |
v v v
Gambar 3: Diagram Urutan pesan yang dipertukarkan antara DHCP
client and servers when allocating a new network address
3. The client receives one or more DHCPOFFER messages from one or more
server. The client may choose to wait for multiple responses.
The client chooses one server from which to request configuration
parameters, based on the configuration parameters offered in the
DHCPOFFER messages. The client broadcasts a DHCPREQUEST message
that MUST include the 'server identifier' option to indicate which
server it has selected, and that MAY include other options
specifying desired configuration values. The 'requested IP
address' option MUST be set to the value of 'yiaddr' in the
DHCPOFFER message from the server. This DHCPREQUEST message is
broadcast and relayed through DHCP/BOOTP relay agents. Membantu
ensure that any BOOTP relay agents forward the DHCPREQUEST message
to the same set of DHCP servers that received the original
DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
value in the DHCP message header's 'secs' field and be sent to the
same IP broadcast address as the original DHCPDISCOVER message.
The client times out and retransmits the DHCPDISCOVER message if
the client receives no DHCPOFFER messages.
4. The servers receive the DHCPREQUEST broadcast from the client.
Those servers not selected by the DHCPREQUEST message use the
message as notification that the client has declined that server's
offer. The server selected in the DHCPREQUEST message commits the
binding for the client to persistent storage and responds with a
DHCPACK message containing the configuration parameters for the
requesting client. The combination of 'client identifier' or
'chaddr' and assigned network address constitute a unique
identifier for the client's lease and are used by both the client
and server to identify a lease referred to in any DHCP messages.
Any configuration parameters in the DHCPACK message SHOULD NOT
conflict with those in the earlier DHCPOFFER message to which the
client is responding. The server SHOULD NOT check the offered
network address at this point. The 'yiaddr' field in the DHCPACK
messages is filled in with the selected network address.
If the selected server is unable to satisfy the DHCPREQUEST message
(e.g., the requested network address has been allocated), the
server SHOULD respond with a DHCPNAK message.
A server MAY choose to mark addresses offered to clients in
DHCPOFFER messages as unavailable. The server SHOULD mark an
address offered to a client in a DHCPOFFER message as available if
the server receives no DHCPREQUEST message from that client.
5. The client receives the DHCPACK message with configuration
parameter. The client SHOULD perform a final check on the
parameters (e.g., ARP for allocated network address), and notes the
duration of the lease specified in the DHCPACK message. At this
point, the client is configured. If the client detects that the
address is already in use (e.g., through the use of ARP), the
client MUST send a DHCPDECLINE message to the server and restarts
the configuration process. The client SHOULD wait a minimum of ten
seconds before restarting the configuration process to avoid
excessive network traffic in case of looping.
If the client receives a DHCPNAK message, the client restarts the
configuration process.
The client times out and retransmits the DHCPREQUEST message if the
client receives neither a DHCPACK or a DHCPNAK message. Klien
retransmits the DHCPREQUEST according to the retransmission
algorithm in section 4.1. The client should choose to retransmit
the DHCPREQUEST enough times to give adequate probability of
contacting the server without causing the client (and the user of
that client) to wait overly long before giving up; e.g., a client
retransmitting as described in section 4.1 might retransmit the
DHCPREQUEST message four times, for a total delay of 60 seconds,
before restarting the initialization procedure. If the client
receives neither a DHCPACK or a DHCPNAK message after employing the
retransmission algorithm, the client reverts to INIT state and
restarts the initialization process. The client SHOULD notify the
user that the initialization process has failed and is restarting.
6. The client may choose to relinquish its lease on a network address
by sending a DHCPRELEASE message to the server. Klien
identifies the lease to be released with its 'client identifier',
or 'chaddr' and network address in the DHCPRELEASE message. Jika
client used a 'client identifier' when it obtained the lease, it
MUST use the same 'client identifier' in the DHCPRELEASE message.
3.2 Client-server interaction - reusing a previously allocated network
alamat
If a client remembers and wishes to reuse a previously allocated
network address, a client may choose to omit some of the steps
described in the previous section. The timeline diagram in figure 4
shows the timing relationships in a typical client-server interaction
for a client reusing a previously allocated network address.
1. The client broadcasts a DHCPREQUEST message on its local subnet.
The message includes the client's network address in the
'requested IP address' option. As the client has not received its
network address, it MUST NOT fill in the 'ciaddr' field. BOOTP
relay agents pass the message on to DHCP servers not on the same
subnet. If the client used a 'client identifier' to obtain its
address, the client MUST use the same 'client identifier' in the
DHCPREQUEST message.
2. Servers with knowledge of the client's configuration parameters
respond with a DHCPACK message to the client. Servers SHOULD NOT
check that the client's network address is already in use; the
client may respond to ICMP Echo Request messages at this point.
Server Client Server
v v v
| | |
| Begins |
| initialization |
| | |
| /|\ |
| _________ __/ | \__________ |
| /DHCPREQU EST | DHCPREQUEST\ |
|/ | \|
| | |
Locates | Locates
configuration | configuration
| | |
|\ | /|
| \ | ___________/ |
| \ | / DHCPACK |
| \ _______ |/ |
| DHCPACK\ | |
| Initialization |
| complete |
| \| |
| | |
| (Subsequent |
| DHCPACKS |
| ignored) |
| | |
| | |
v v v
Figure 4: Timeline diagram of messages exchanged between DHCP
client and servers when reusing a previously allocated
network address
If the client's request is invalid (e.g., the client has moved
to a new subnet), servers SHOULD respond with a DHCPNAK message to
klien. Servers SHOULD NOT respond if their information is not
guaranteed to be accurate. For example, a server that identifies a
request for an expired binding that is owned by another server SHOULD
NOT respond with a DHCPNAK unless the servers are using an explicit
mechanism to maintain coherency among the servers.
If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
the same subnet as the server. The server MUST
broadcast the DHCPNAK message to the 0xffffffff broadcast address
because the client may not have a correct network address or subnet
mask, and the client may not be answering ARP requests.
Otherwise, the server MUST send the DHCPNAK message to the IP
address of the BOOTP relay agent, as recorded in 'giaddr'. Itu
relay agent will, in turn, forward the message directly to the
client's hardware address, so that the DHCPNAK can be delivered even
if the client has moved to a new network.
3. The client receives the DHCPACK message with configuration
parameter. The client performs a final check on the parameters
(as in section 3.1), and notes the duration of the lease specified
in the DHCPACK message. The specific lease is implicitly identified
by the 'client identifier' or 'chaddr' and the network address. Di
this point, the client is configured.
If the client detects that the IP address in the DHCPACK message
is already in use, the client MUST send a DHCPDECLINE message to the
server and restarts the configuration process by requesting a
new network address. This action corresponds to the client
moving to the INIT state in the DHCP state diagram, which is
described in section 4.4.
If the client receives a DHCPNAK message, it cannot reuse its
remembered network address. It must instead request a new
address by restarting the configuration process, this time
using the (non-abbreviated) procedure described in section
3.1. This action also corresponds to the client moving to
the INIT state in the DHCP state diagram.
The client times out and retransmits the DHCPREQUEST message if
the client receives neither a DHCPACK nor a DHCPNAK message. Itu
client retransmits the DHCPREQUEST according to the retransmission
algorithm in section 4.1. The client should choose to retransmit
the DHCPREQUEST enough times to give adequate probability of
contacting the server without causing the client (and the user of
that client) to wait overly long before giving up; e.g., a client
retransmitting as described in section 4.1 might retransmit the
DHCPREQUEST message four times, for a total delay of 60 seconds,
before restarting the initialization procedure. If the client
receives neither a DHCPACK or a DHCPNAK message after employing
the retransmission algorithm, the client MAY choose to use the
previously allocated network address and configuration parameters
for the remainder of the unexpired lease. This corresponds to
moving to BOUND state in the client state transition diagram shown
in figure 5.
4. The client may choose to relinquish its lease on a network
address by sending a DHCPRELEASE message to the server. Itu
client identifies the lease to be released with its
'client identifier', or 'chaddr' and network address in the
DHCPRELEASE message.
Note that in this case, where the client retains its network
address locally, the client will not normally relinquish its
lease during a graceful shutdown. Only in the case where the
client explicitly needs to relinquish its lease, e.g., the client
is about to be moved to a different subnet, will the client send
a DHCPRELEASE message.
3.3 Interpretation and representation of time values
A client acquires a lease for a network address for a fixed period of
time (which may be infinite). Throughout the protocol, times are to
be represented in units of seconds. The time value of 0xffffffff is
reserved to represent "infinity".
As clients and servers may not have synchronized clocks, times are
represented in DHCP messages as relative times, to be interpreted
with respect to the client's local clock. Representing relative
times in units of seconds in an unsigned 32 bit word gives a range of
relative times from 0 to approximately 100 years, which is sufficient
for the relative times to be measured using DHCP.
The algorithm for lease duration interpretation given in the previous
paragraph assumes that client and server clocks are stable relative
to each other. If there is drift between the two clocks, the server
may consider the lease expired before the client does. Untuk
compensate, the server may return a shorter lease duration to the
client than the server commits to its local database of client
informasi.
3.4 Obtaining parameters with externally configured network address
If a client has obtained a network address through some other means
(e.g., manual configuration), it may use a DHCPINFORM request message
to obtain other local configuration parameters. Servers receiving a
DHCPINFORM message construct a DHCPACK message with any local
configuration parameters appropriate for the client without:
allocating a new address, checking for an existing binding, filling
in 'yiaddr' or including lease time parameters. The servers SHOULD
unicast the DHCPACK reply to the address given in the 'ciaddr' field
of the DHCPINFORM message.
The server SHOULD check the network address in a DHCPINFORM message
for consistency, but MUST NOT check for an existing lease. Itu
server forms a DHCPACK message containing the configuration
parameters for the requesting client and sends the DHCPACK message
directly to the client.
3.5 Client parameters in DHCP
Not all clients require initialization of all parameters listed in
Appendix A. Two techniques are used to reduce the number of
parameters transmitted from the server to the client. First, most of
the parameters have defaults defined in the Host Requirements RFCs;
if the client receives no parameters from the server that override
the defaults, a client uses those default values. Second, in its
initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the
server with a list of specific parameters the client is interested
in. If the client includes a list of parameters in a DHCPDISCOVER
message, it MUST include that list in any subsequent DHCPREQUEST
pesan.
The client SHOULD include the 'maximum DHCP message size' option to
let the server know how large the server may make its DHCP messages.
The parameters returned to a client may still exceed the space
allocated to options in a DHCP message. In this case, two additional
options flags (which must appear in the 'options' field of the
message) indicate that the 'file' and 'sname' fields are to be used
for options.
The client can inform the server which configuration parameters the
client is interested in by including the 'parameter request list'
pilihan. The data portion of this option explicitly lists the options
requested by tag number.
In addition, the client may suggest values for the network address
and lease time in the DHCPDISCOVER message. The client may include
the 'requested IP address' option to suggest that a particular IP
address be assigned, and may include the 'IP address lease time'
option to suggest the lease time it would like. Other options
representing "hints" at configuration parameters are allowed in a
DHCPDISCOVER or DHCPREQUEST message. However, additional options may
be ignored by servers, and multiple servers may, therefore, not
return identical values for some options. The 'requested IP address'
option is to be filled in only in a DHCPREQUEST message when the
client is verifying network parameters obtained previously. Itu
client fills in the 'ciaddr' field only when correctly configured
with an IP address in BOUND, RENEWING or REBINDING state.
If a server receives a DHCPREQUEST message with an invalid 'requested
IP address', the server SHOULD respond to the client with a DHCPNAK
message and may choose to report the problem to the system
administrator. The server may include an error message in the
'message' option.
3.6 Use of DHCP in clients with multiple interfaces
A client with multiple network interfaces must use DHCP through each
interface independently to obtain configuration information
parameters for those separate interfaces.
3.7 When clients should use DHCP
A client SHOULD use DHCP to reacquire or verify its IP address and
network parameters whenever the local network parameters may have
changed; e.g., at system boot time or after a disconnection from the
local network, as the local network configuration may change without
the client's or user's knowledge.
If a client has knowledge of a previous network address and is unable
to contact a local DHCP server, the client may continue to use the
previous network address until the lease for that address expires.
If the lease expires before the client can contact a DHCP server, the
client must immediately discontinue use of the previous network
address and may inform local users of the problem.
4. Specification of the DHCP client-server protocol
In this section, we assume that a DHCP server has a block of network
addresses from which it can satisfy requests for new addresses. Tiap
server also maintains a database of allocated addresses and leases in
local permanent storage.
4.1 Constructing and sending DHCP messages
DHCP clients and servers both construct DHCP messages by filling in
fields in the fixed format section of the message and appending
tagged data items in the variable length option area. The options
area includes first a four-octet 'magic cookie' (which was described
in section 3), followed by the options. The last option must always
be the 'end' option.
DHCP uses UDP as its transport protocol. DHCP messages from a client
to a server are sent to the 'DHCP server' port (67), and DHCP
messages from a server to a client are sent to the 'DHCP client' port
(68). A server with multiple network address (e.g., a multi-homed
host) MAY use any of its network addresses in outgoing DHCP messages.
The 'server identifier' field is used both to identify a DHCP server
in a DHCP message and as a destination address from clients to
server. A server with multiple network addresses MUST be prepared
to to accept any of its network addresses as identifying that server
in a DHCP message. To accommodate potentially incomplete network
connectivity, a server MUST choose an address as a 'server
identifier' that, to the best of the server's knowledge, is reachable
from the client. For example, if the DHCP server and the DHCP client
are connected to the same subnet (i.e., the 'giaddr' field in the
message from the client is zero), the server SHOULD select the IP
address the server is using for communication on that subnet as the
'server identifier'. If the server is using multiple IP addresses on
that subnet, any such address may be used. If the server has
received a message through a DHCP relay agent, the server SHOULD
choose an address from the interface on which the message was
recieved as the 'server identifier' (unless the server has other,
better information on which to make its choice). DHCP clients MUST
use the IP address provided in the 'server identifier' option for any
unicast requests to the DHCP server.
DHCP messages broadcast by a client prior to that client obtaining
its IP address must have the source address field in the IP header
set to 0.
If the 'giaddr' field in a DHCP message from a client is non-zero,
the server sends any return messages to the 'DHCP server' port on the
BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
field is zero and the 'ciaddr' field is nonzero, then the server
unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
set, then the server broadcasts DHCPOFFER and DHCPACK messages to
0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
messages to the client's hardware address and 'yiaddr' address. Di
all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
messages to 0xffffffff.
If the options in a DHCP message extend into the 'sname' and 'file'
fields, the 'option overload' option MUST appear in the 'options'
field, with value 1, 2 or 3, as specified in RFC 1533. Jika
'option overload' option is present in the 'options' field, the
options in the 'options' field MUST be terminated by an 'end' option,
and MAY contain one or more 'pad' options to fill the options field.
The options in the 'sname' and 'file' fields (if in use as indicated
by the 'options overload' option) MUST begin with the first octet of
the field, MUST be terminated by an 'end' option, and MUST be
followed by 'pad' options to fill the remainder of the field. Sembarang
individual option in the 'options', 'sname' and 'file' fields MUST be
entirely contained in that field. The options in the 'options' field
MUST be interpreted first, so that any 'option overload' options may
be interpreted. The 'file' field MUST be interpreted next (if the
'option overload' option indicates that the 'file' field contains
DHCP options), followed by the 'sname' field.
The values to be passed in an 'option' tag may be too long to fit in
the 255 octets available to a single option (e.g., a list of routers
in a 'router' option [21]). Options may appear only once, unless
otherwise specified in the options document. The client concatenates
the values of multiple instances of the same option into a single
parameter list for configuration.
DHCP clients are responsible for all message retransmission. Itu
client MUST adopt a retransmission strategy that incorporates a
randomized exponential backoff algorithm to determine the delay
between retransmissions. The delay between retransmissions SHOULD be
chosen to allow sufficient time for replies from the server to be
delivered based on the characteristics of the internetwork between
the client and the server. For example, in a 10Mb/sec Ethernet
internetwork, the delay before the first retransmission SHOULD be 4
seconds randomized by the value of a uniform random number chosen
from the range -1 to +1. Clients with clocks that provide resolution
granularity of less than one second may choose a non-integer
randomization value. The delay before the next retransmission SHOULD
be 8 seconds randomized by the value of a uniform number chosen from
the range -1 to +1. The retransmission delay SHOULD be doubled with
subsequent retransmissions up to a maximum of 64 seconds. Klien
MAY provide an indication of retransmission attempts to the user as
an indication of the progress of the configuration process.
The 'xid' field is used by the client to match incoming DHCP messages
with pending requests. A DHCP client MUST choose 'xid's in such a
way as to minimize the chance of using an 'xid' identical to one used
by another client. For example, a client may choose a different,
random initial 'xid' each time the client is rebooted, and
subsequently use sequential 'xid's until the next reboot. Selecting
a new 'xid' for each retransmission is an implementation decision. Sebuah
client may choose to reuse the same 'xid' or select a new 'xid' for
each retransmitted message.
Normally, DHCP servers and BOOTP relay agents attempt to deliver
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
uicast delivery. The IP destination address (in the IP header) is
set to the DHCP 'yiaddr' address and the link-layer destination
address is set to the DHCP 'chaddr' address. Unfortunately, some
client implementations are unable to receive such unicast IP
datagrams until the implementation has been configured with a valid
IP address (leading to a deadlock in which the client's IP address
cannot be delivered until the client has been configured with an IP
alamat).
A client that cannot receive unicast IP datagrams until its protocol
software has been configured with an IP address SHOULD set the
BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
DHCPREQUEST messages that client sends. The BROADCAST bit will
provide a hint to the DHCP server and BOOTP relay agent to broadcast
any messages to the client on the client's subnet. A client that can
receive unicast IP datagrams before its protocol software has been
configured SHOULD clear the BROADCAST bit to 0. The BOOTP
clarifications document discusses the ramifications of the use of the
BROADCAST bit [21].
A server or relay agent sending or relaying a DHCP message directly
to a DHCP client (i.e., not to a relay agent specified in the
'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
lapangan. If this bit is set to 1, the DHCP message SHOULD be sent as
an IP broadcast using an IP broadcast address (preferably 0xffffffff)
as the IP destination address and the link-layer broadcast address as
the link-layer destination address. If the BROADCAST bit is cleared
to 0, the message SHOULD be sent as an IP unicast to the IP address
specified in the 'yiaddr' field and the link-layer address specified
in the 'chaddr' field. If unicasting is not possible, the message
MAY be sent as an IP broadcast using an IP broadcast address
(preferably 0xffffffff) as the IP destination address and the link-
layer broadcast address as the link-layer destination address.
4.2 DHCP server administrative controls
DHCP servers are not required to respond to every DHCPDISCOVER and
DHCPREQUEST message they receive. For example, a network
administrator, to retain stringent control over the clients attached
to the network, may choose to configure DHCP servers to respond only
to clients that have been previously registered through some external
mekanisme. The DHCP specification describes only the interactions
between clients and servers when the clients and servers choose to
interact; it is beyond the scope of the DHCP specification to
describe all of the administrative controls that system
administrators might want to use. Specific DHCP server
implementations may incorporate any controls or policies desired by a
network administrator.
In some environments, a DHCP server will have to consider the values
of the vendor class options included in DHCPDISCOVER or DHCPREQUEST
messages when determining the correct parameters for a particular
klien.
A DHCP server needs to use some unique identifier to associate a
client with its lease. The client MAY choose to explicitly provide
the identifier through the 'client identifier' option. If the client
supplies a 'client identifier', the client MUST use the same 'client
identifier' in all subsequent messages, and the server MUST use that
identifier to identify the client. If the client does not provide a
'client identifier' option, the server MUST use the contents of the
'chaddr' field to identify the client. It is crucial for a DHCP
client to use an identifier unique within the subnet to which the
client is attached in the 'client identifier' option. Use of
'chaddr' as the client's unique identifier may cause unexpected
results, as that identifier may be associated with a hardware
interface that could be moved to a new client. Some sites may choose
to use a manufacturer's serial number as the 'client identifier', to
avoid unexpected changes in a clients network address due to transfer
of hardware interfaces among computers. Sites may also choose to use
a DNS name as the 'client identifier', causing address leases to be
associated with the DNS name rather than a specific hardware box.
DHCP clients are free to use any strategy in selecting a DHCP server
among those from which the client receives a DHCPOFFER message. Itu
client implementation of DHCP SHOULD provide a mechanism for the user
to select directly the 'vendor class identifier' values.
4.3 DHCP server behavior
A DHCP server processes incoming DHCP messages from a client based on
the current state of the binding for that client. A DHCP server can
receive the following messages from a client:
o DHCPDISCOVER
o DHCPREQUEST
o DHCPDECLINE
o DHCPRELEASE
o DHCPINFORM
Droms Standards Track [Page 26]
RFC 2131 Dynamic Host Configuration Protocol March 1997
Table 3 gives the use of the fields and options in a DHCP message by
a server. The remainder of this section describes the action of the
DHCP server for each possible incoming message.
4.3.1 DHCPDISCOVER message
When a server receives a DHCPDISCOVER message from a client, the
server chooses a network address for the requesting client. If no
address is available, the server may choose to report the problem to
the system administrator. If an address is available, the new address
SHOULD be chosen as follows:
o The client's current address as recorded in the client's current
binding, ELSE
o The client's previous address as recorded in the client's (now
expired or released) binding, if that address is in the server's
pool of available addresses and not already allocated, ELSE
o The address requested in the 'Requested IP Address' option, if that
address is valid and not already allocated, ELSE
o A new address allocated from the server's pool of available
addresses; the address is selected based on the subnet from which
the message was received (if 'giaddr' is 0) or on the address of
the relay agent that forwarded the message ('giaddr' when not 0).
As described in section 4.2, a server MAY, for administrative
reasons, assign an address other than the one requested, or may
refuse to allocate an address to a particular client even though free
addresses are available.
Note that, in some network architectures (e.g., internets with more
than one IP subnet assigned to a physical network segment), it may be
the case that the DHCP client should be assigned an address from a
different subnet than the address recorded in 'giaddr'. Thus, DHCP
does not require that the client be assigned as address from the
subnet in 'giaddr'. A server is free to choose some other subnet,
and it is beyond the scope of the DHCP specification to describe ways
in which the assigned IP address might be chosen.
While not required for correct operation of DHCP, the server SHOULD
NOT reuse the selected network address before the client responds to
the server's DHCPOFFER message. The server may choose to record the
address as offered to the client.
The server must also choose an expiration time for the lease, as
berikut
o IF the client has not requested a specific lease in the
DHCPDISCOVER message and the client already has an assigned network
address, the server returns the lease expiration time previously
assigned to that address (note that the client must explicitly
request a specific lease to extend the expiration time on a
previously assigned address), ELSE
o IF the client has not requested a specific lease in the
DHCPDISCOVER message and the client does not have an assigned
network address, the server assigns a locally configured default
lease time, ELSE
o IF the client has requested a specific lease in the DHCPDISCOVER
message (regardless of whether the client has an assigned network
address), the server may choose either to return the requested
lease (if the lease is acceptable to local policy) or select
another lease.
Field DHCPOFFER DHCPACK DHCPNAK
----- --------- ------- -------
'op' BOOTREPLY BOOTREPLY BOOTREPLY
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' 'xid' from client 'xid' from client 'xid' from client
DHCPDISCOVER DHCPREQUEST DHCPREQUEST
message message message
'secs' 0 0 0
'ciaddr' 0 'ciaddr' from 0
DHCPREQUEST or 0
'yiaddr' IP address offered IP address 0
to client assigned to client
'siaddr' IP address of next IP address of next 0
bootstrap server bootstrap server
'flags' 'flags' from 'flags' from 'flags' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'sname' Server host name Server host name (unused)
or options or options
'file' Client boot file Client boot file (unused)
name or options name or options
'options' options options
Option DHCPOFFER DHCPACK DHCPNAK
------ --------- ------- -------
Requested IP address MUST NOT MUST NOT MUST NOT
IP address lease time MUST MUST (DHCPREQUEST) MUST NOT
MUST NOT (DHCPINFORM)
Use 'file'/'sname' fields MAY MAY MUST NOT
DHCP message type DHCPOFFER DHCPACK DHCPNAK
Parameter request list MUST NOT MUST NOT MUST NOT
Message SHOULD SHOULD SHOULD
Client identifier MUST NOT MUST NOT MAY
Vendor class identifier MAY MAY MAY
Server identifier MUST MUST MUST
Maximum message size MUST NOT MUST NOT MUST NOT
All others MAY MAY MUST NOT
Table 3: Fields and options used by DHCP servers
Once the network address and lease have been determined, the server
constructs a DHCPOFFER message with the offered configuration
parameter. It is important for all DHCP servers to return the same
parameters (with the possible exception of a newly allocated network
address) to ensure predictable client behavior regardless of which
server the client selects. The configuration parameters MUST be
selected by applying the following rules in the order given below.
The network administrator is responsible for configuring multiple
DHCP servers to ensure uniform responses from those servers. Itu
server MUST return to the client:
o The client's network address, as determined by the rules given
earlier in this section,
o The expiration time for the client's lease, as determined by the
rules given earlier in this section,
o Parameters requested by the client, according to the following
rules:
-- IF the server has been explicitly configured with a default
value for the parameter, the server MUST include that value
in an appropriate option in the 'option' field, ELSE
-- IF the server recognizes the parameter as a parameter
defined in the Host Requirements Document, the server MUST
include the default value for that parameter as given in the
Host Requirements Document in an appropriate option in the
'option' field, ELSE
-- The server MUST NOT return a value for that parameter,
The server MUST supply as many of the requested parameters as
possible and MUST omit any parameters it cannot provide. Itu
server MUST include each requested parameter only once unless
explicitly allowed in the DHCP Options and BOOTP Vendor
Extensions document.
o Any parameters from the existing binding that differ from the Host
Requirements Document defaults,
o Any parameters specific to this client (as identified by
the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER
or DHCPREQUEST message), e.g., as configured by the network
administrator,
o Any parameters specific to this client's class (as identified
by the contents of the 'vendor class identifier'
option in the DHCPDISCOVER or DHCPREQUEST message),
e.g., as configured by the network administrator; the parameters
MUST be identified by an exact match between the client's vendor
class identifiers and the client's classes identified in the
server,
o Parameters with non-default values on the client's subnet.
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 server inserts
the 'xid' field from the DHCPDISCOVER message into the 'xid' field of
the DHCPOFFER message and sends the DHCPOFFER message to the
requesting client.
4.3.2 DHCPREQUEST message
A DHCPREQUEST message may come from a client responding to a
DHCPOFFER message from a server, from a client verifying a previously
allocated IP address or from a client extending the lease on a
network address. If the DHCPREQUEST message contains a 'server
identifier' option, the message is in response to a DHCPOFFER
pesan. Otherwise, the message is a request to verify or extend an
existing lease. If the client uses a 'client identifier' in a
DHCPREQUEST message, it MUST use that same 'client identifier' in all
subsequent messages. If the client included a list of requested
parameters in a DHCPDISCOVER message, it MUST include that list in
all subsequent messages.
Any configuration parameters in the DHCPACK message SHOULD NOT
conflict with those in the earlier DHCPOFFER message to which the
client is responding. The client SHOULD use the parameters in the
DHCPACK message for configuration.
Clients send DHCPREQUEST messages as follows:
o DHCPREQUEST generated during SELECTING state:
Client inserts the address of the selected server in 'server
identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be
filled in with the yiaddr value from the chosen DHCPOFFER.
Note that the client may choose to collect several DHCPOFFER
messages and select the "best" offer. The client indicates its
selection by identifying the offering server in the DHCPREQUEST
pesan. If the client receives no acceptable offers, the client
may choose to try another DHCPDISCOVER message. Oleh karena itu,
servers may not receive a specific DHCPREQUEST from which they can
decide whether or not the client has accepted the offer. Karena
the servers have not committed any network address assignments on
the basis of a DHCPOFFER, servers are free to reuse offered
network addresses in response to subsequent requests. As an
implementation detail, servers SHOULD NOT reuse offered addresses
and may use an implementation-specific timeout mechanism to decide
when to reuse an offered address.
o DHCPREQUEST generated during INIT-REBOOT state:
'server identifier' MUST NOT be filled in, 'requested IP address'
option MUST be filled in with client's notion of its previously
assigned address. 'ciaddr' MUST be zero. The client is seeking to
verify a previously allocated, cached configuration. Server SHOULD
send a DHCPNAK message to the client if the 'requested IP address'
is incorrect, or is on the wrong network.
Determining whether a client in the INIT-REBOOT state is on the
correct network is done by examining the contents of 'giaddr', the
'requested IP address' option, and a database lookup. If the DHCP
server detects that the client is on the wrong net (i.e., the
result of applying the local subnet mask or remote subnet mask (if
'giaddr' is not zero) to 'requested IP address' option value
doesn't match reality), then the server SHOULD send a DHCPNAK
message to the client.
If the network is correct, then the DHCP server should check if
the client's notion of its IP address is correct. If not, then the
server SHOULD send a DHCPNAK message to the client. If the DHCP
server has no record of this client, then it MUST remain silent,
and MAY output a warning to the network administrator. Ini
behavior is necessary for peaceful coexistence of non-
communicating DHCP servers on the same wire.
If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
the same subnet as the server. The server MUST broadcast the
DHCPNAK message to the 0xffffffff broadcast address because the
client may not have a correct network address or subnet mask, and
the client may not be answering ARP requests.
If 'giaddr' is set in the DHCPREQUEST message, the client is on a
different subnet. The server MUST set the broadcast bit in the
DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
client, because the client may not have a correct network address
or subnet mask, and the client may not be answering ARP requests.
o DHCPREQUEST generated during RENEWING state:
'server identifier' MUST NOT be filled in, 'requested IP address'
option MUST NOT be filled in, 'ciaddr' MUST be filled in with
client's IP address. In this situation, the client is completely
configured, and is trying to extend its lease. This message will
be unicast, so no relay agents will be involved in its
transmisi. Because 'giaddr' is therefore not filled in, the
DHCP server will trust the value in 'ciaddr', and use it when
replying to the client.
A client MAY choose to renew or extend its lease prior to T1. Itu
server may choose not to extend the lease (as a policy decision by
the network administrator), but should return a DHCPACK message
regardless.
o DHCPREQUEST generated during REBINDING state:
'server identifier' MUST NOT be filled in, 'requested IP address'
option MUST NOT be filled in, 'ciaddr' MUST be filled in with
client's IP address. In this situation, the client is completely
configured, and is trying to extend its lease. This message MUST
be broadcast to the 0xffffffff IP broadcast address. The DHCP
server SHOULD check 'ciaddr' for correctness before replying to
the DHCPREQUEST.
The DHCPREQUEST from a REBINDING client is intended to accommodate
sites that have multiple DHCP servers and a mechanism for
maintaining consistency among leases managed by multiple servers.
A DHCP server MAY extend a client's lease only if it has local
administrative authority to do so.
4.3.3 DHCPDECLINE message
If the server receives a DHCPDECLINE message, the client has
discovered through some other means that the suggested network
address is already in use. The server MUST mark the network address
as not available and SHOULD notify the local system administrator of
a possible configuration problem.
4.3.4 DHCPRELEASE message
Upon receipt of a DHCPRELEASE message, the server marks the network
address as not allocated. The server SHOULD retain a record of the
client's initialization parameters for possible reuse in response to
subsequent requests from the client.
4.3.5 DHCPINFORM message
The server responds to a DHCPINFORM message by sending a DHCPACK
message directly to the address given in the 'ciaddr' field of the
DHCPINFORM message. The server MUST NOT send a lease expiration time
to the client and SHOULD NOT fill in 'yiaddr'. The server includes
other parameters in the DHCPACK message as defined in section 4.3.1.
4.3.6 Client messages
Table 4 details the differences between messages from clients in
various states.
-------------------------------------------------- -------------------
| |INIT-REBOOT |SELECTING |RENEWING |REBINDING |
-------------------------------------------------- -------------------
|broad/unicast |broadcast |broadcast |unicast |broadcast |
|server-ip |MUST NOT |MUST |MUST NOT |MUST NOT |
|requested-ip |MUST |MUST |MUST NOT |MUST NOT |
|ciaddr |zero |zero |IP address |IP address|
-------------------------------------------------- -------------------
Table 4: Client messages from different states
4.4 DHCP client behavior
Figure 5 gives a state-transition diagram for a DHCP client. Sebuah
client can receive the following messages from a server:
o DHCPOFFER
o DHCPACK
o DHCPNAK
The DHCPINFORM message is not shown in figure 5. A client simply
sends the DHCPINFORM and waits for DHCPACK messages. Once the client
has selected its parameters, it has completed the configuration
proses.
Table 5 gives the use of the fields and options in a DHCP message by
a client. The remainder of this section describes the action of the
DHCP client for each possible incoming message. The description in
the following section corresponds to the full configuration procedure
previously described in section 3.1, and the text in the subsequent
section corresponds to the abbreviated configuration procedure
described in section 3.2.
-------- -------
| | +-------------------------->| |<-------------------+ | INIT- | | +-------------------->| INIT | |
| REBOOT |DHCPNAK/ +---------->| |<---+ | | |Restart| | ------- | | -------- | DHCPNAK/ | | | | Discard offer | -/Send DHCPDISCOVER | -/Send DHCPREQUEST | | | | | | DHCPACK v | | ----------- | (not accept.)/ ----------- | | | | | Send DHCPDECLINE | | | | REBOOTING | | | | SELECTING |<----+ | | | | / | | |DHCPOFFER/ | ----------- | / ----------- | |Collect | | | / | | | replies | DHCPACK/ | / +----------------+ +-------+ | Record lease, set| | v Select offer/ | timers T1, T2 ------------ send DHCPREQUEST | | | +----->| | DHCPNAK, Lease expired/ |
| | | REQUESTING | Halt network |
DHCPOFFER/ | | | |
Discard ------------ | |
| | | | ----------- |
| +--------+ DHCPACK/ | | |
| Record lease, set -----| REBINDING | |
| timers T1, T2 / | | |
| | DHCPACK/ ----------- |
| v Record lease, set ^ |
+----------------> ------- /timers T1,T2 | |
+----->| |<---+ | | | | BOUND |<---+ | | DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/ DHCPNAK/Discard ------- | Broadcast Halt network | | | | DHCPREQUEST | +-------+ | DHCPACK/ | | T1 expires/ Record lease, set | | Send DHCPREQUEST timers T1, T2 | | to leasing server | | | | ---------- | | | | |------------+ | +->| RENEWING | |
| |----------------------------+
----------
Figure 5: State-transition diagram for DHCP clients
Droms Standards Track [Page 35]
RFC 2131 Dynamic Host Configuration Protocol March 1997
4.4.1 Initialization and allocation of network address
The client begins in INIT state and forms a DHCPDISCOVER message.
The client SHOULD wait a random time between one and ten seconds to
desynchronize the use of DHCP at startup. The client sets 'ciaddr'
to 0x00000000. The client MAY request specific parameters by
including the 'parameter request list' option. The client MAY
suggest a network address and/or lease time by including the
'requested IP address' and 'IP address lease time' options. Itu
client MUST include its hardware address in the 'chaddr' field, if
necessary for delivery of DHCP reply messages. The client MAY
include a different unique identifier in the 'client identifier'
option, as discussed in section 4.2. If the client included a list
of requested parameters in a DHCPDISCOVER message, it MUST include
that list in all subsequent messages.
The client generates and records a random transaction identifier and
inserts that identifier into the 'xid' field. The client records its
own local time for later use in computing the lease expiration. Itu
client then broadcasts the DHCPDISCOVER on the local hardware
broadcast address to the 0xffffffff IP broadcast address and 'DHCP
server' UDP port.
If the 'xid' of an arriving DHCPOFFER message does not match the
'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message
must be silently discarded. Any arriving DHCPACK messages must be
silently discarded.
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.
Droms Standards Track [Page 36]
RFC 2131 Dynamic Host Configuration Protocol March 1997
Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPINFORM DHCPRELEASE
----- ------------ ----------- -----------
'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' selected by client 'xid' from server selected by
DHCPOFFER message client
'secs' 0 or seconds since 0 or seconds since 0
DHCP process started DHCP process started
'flags' Set 'BROADCAST' Set 'BROADCAST' 0
flag if client flag if client
requires broadcast requires broadcast
reply reply
'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE)
client's network address client's network
network address (BOUND/RENEW/REBIND) address
(DHCPINFORM) (DHCPRELEASE)
'yiaddr' 0 0 0
'siaddr' 0 0 0
'giaddr' 0 0 0
'chaddr' client's hardware client's hardware client's hardware
address address address
'sname' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
unused unused
'file' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
unused unused
'options' options options (unused)
Droms Standards Track [Page 37]
RFC 2131 Dynamic Host Configuration Protocol March 1997
Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPINFORM DHCPRELEASE
------ ------------ ----------- -----------
Requested IP address MAY MUST (in MUST
(DISCOVER) SELECTING or (DHCPDECLINE),
MUST NOT INIT-REBOOT) MUST NOT
(INFORM) MUST NOT (in (DHCPRELEASE)
BOUND or
RENEWING)
IP address lease time MAY MAY MUST NOT
(DISCOVER)
MUST NOT
(INFORM)
Use 'file'/'sname' fields MAY MAY MAY
DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/
DHCPINFORM DHCPRELEASE
Client identifier MAY MAY MAY
Vendor class identifier MAY MAY MUST NOT
Server identifier MUST NOT MUST (after MUST
SELECTING)
MUST NOT (after
INIT-REBOOT,
BOUND, RENEWING
or REBINDING)
Parameter request list MAY MAY MUST NOT
Maximum message size MAY MAY MUST NOT
Message SHOULD NOT SHOULD NOT SHOULD
Site-specific MAY MAY MUST NOT
All others MAY MAY MUST NOT
Table 5: Fields and options used by DHCP clients
If the parameters are acceptable, the client records the address of
the server that supplied the parameters from the 'server identifier'
field and sends that address in the 'server identifier' field of a
DHCPREQUEST broadcast message. Once the DHCPACK message from the
server arrives, the client is initialized and moves to BOUND state.
The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER
pesan. The client records the lease expiration time as the sum of
the time at which the original request was sent and the duration of
the lease from the DHCPACK message. The client SHOULD perform a
check on the suggested address to ensure that the address is not
already in use. For example, if the client is on a network that
supports ARP, the client may issue an ARP request for the suggested
request. When broadcasting an ARP request for the suggested address,
the client must fill in its own hardware address as the sender's
hardware address, and 0 as the sender's IP address, to avoid
confusing ARP caches in other hosts on the same subnet. Jika
network address appears to be in use, the client MUST send a
DHCPDECLINE message to the server. The client SHOULD broadcast an ARP
reply to announce the client's new IP address and clear any outdated
ARP cache entries in hosts on the client's subnet.
4.4.2 Initialization with known network address
The client begins in INIT-REBOOT state and sends a DHCPREQUEST
pesan. The client MUST insert its known network address as a
'requested IP address' option in the DHCPREQUEST message. Klien
may request specific configuration parameters by including the
'parameter request list' option. The client generates and records a
random transaction identifier and inserts that identifier into the
'xid' field. The client records its own local time for later use in
computing the lease expiration. The client MUST NOT include a
'server identifier' in the DHCPREQUEST message. The client then
broadcasts the DHCPREQUEST on the local hardware broadcast address to
the 'DHCP server' UDP port.
Once a DHCPACK message with an 'xid' field matching that in the
client's DHCPREQUEST message arrives from any server, the client is
initialized and moves to BOUND state. The client records the lease
expiration time as the sum of the time at which the DHCPREQUEST
message was sent and the duration of the lease from the DHCPACK
pesan.
4.4.3 Initialization with an externally assigned network address
The client sends a DHCPINFORM message. The client may request
specific configuration parameters by including the 'parameter request
list' option. The client generates and records a random transaction
identifier and inserts that identifier into the 'xid' field. Itu
client places its own network address in the 'ciaddr' field. Itu
client SHOULD NOT request lease time parameters.
The client then unicasts the DHCPINFORM to the DHCP server if it
knows the server's address, otherwise it broadcasts the message to
the limited (all 1s) broadcast address. DHCPINFORM messages MUST be
directed to the 'DHCP server' UDP port.
Once a DHCPACK message with an 'xid' field matching that in the
client's DHCPINFORM message arrives from any server, the client is
initialized.
If the client does not receive a DHCPACK within a reasonable period
of time (60 seconds or 4 tries if using timeout suggested in section
4.1), then it SHOULD display a message informing the user of the
problem, and then SHOULD begin network processing using suitable
defaults as per Appendix A.
4.4.4 Use of broadcast and unicast
The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
messages, unless the client knows the address of a DHCP server. Itu
client unicasts DHCPRELEASE messages to the server. Karena
client is declining the use of the IP address supplied by the server,
the client broadcasts DHCPDECLINE messages.
When the DHCP client knows the address of a DHCP server, in either
INIT or REBOOTING state, the client may use that address in the
DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
The client may also use unicast to send DHCPINFORM messages to a
known DHCP server. If the client receives no response to DHCP
messages sent to the IP address of a known DHCP server, the DHCP
client reverts to using the IP broadcast address.
4.4.5 Reacquisition and expiration
The client maintains two times, T1 and T2, that specify the times at
which the client tries to extend its lease on its network address.
T1 is the time at which the client enters the RENEWING state and
attempts to contact the server that originally issued the client's
network address. T2 is the time at which the client enters the
REBINDING state and attempts to contact any server. T1 MUST be
earlier than T2, which, in turn, MUST be earlier than the time at
which the client's lease will expire.
To avoid the need for synchronized clocks, T1 and T2 are expressed in
options as relative times [2].
At time T1 the client moves to RENEWING state and sends (via unicast)
a DHCPREQUEST message to the server to extend its lease. Klien
sets the 'ciaddr' field in the DHCPREQUEST to its current network
alamat. The client records the local time at which the DHCPREQUEST
message is sent for computation of the lease expiration time. Itu
client MUST NOT include a 'server identifier' in the DHCPREQUEST
pesan.
Any DHCPACK messages that arrive with an 'xid' that does not match
the 'xid' of the client's DHCPREQUEST message are silently discarded.
When the client receives a DHCPACK from the server, the client
computes the lease expiration time as the sum of the time at which
the client sent the DHCPREQUEST message and the duration of the lease
in the DHCPACK message. The client has successfully reacquired its
network address, returns to BOUND state and may continue network
processing.
If no DHCPACK arrives before time T2, the client moves to REBINDING
state and sends (via broadcast) a DHCPREQUEST message to extend its
lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its
current network address. The client MUST NOT include a 'server
identifier' in the DHCPREQUEST message.
Times T1 and T2 are configurable by the server through options. T1
defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 *
duration_of_lease). Times T1 and T2 SHOULD be chosen with some
random "fuzz" around a fixed value, to avoid synchronization of
client reacquisition.
A client MAY choose to renew or extend its lease prior to T1. Itu
server MAY choose to extend the client's lease according to policy
set by the network administrator. The server SHOULD return T1 and
T2, and their values SHOULD be adjusted from their original values to
take account of the time remaining on the lease.
In both RENEWING and REBINDING states, if the client receives no
response to its DHCPREQUEST message, the client SHOULD wait one-half
of the remaining time until T2 (in RENEWING state) and one-half of
the remaining lease time (in REBINDING state), down to a minimum of
60 seconds, before retransmitting the DHCPREQUEST message.
If the lease expires before the client receives a DHCPACK, the client
moves to INIT state, MUST immediately stop any other network
processing and requests network initialization parameters as if the
client were uninitialized. If the client then receives a DHCPACK
allocating that client its previous network address, the client
SHOULD continue network processing. If the client is given a new
network address, it MUST NOT continue using the previous network
address and SHOULD notify the local users of the problem.
4.4.6 DHCPRELEASE
If the client no longer requires use of its assigned network address
(e.g., the client is gracefully shut down), the client sends a
DHCPRELEASE message to the server. Note that the correct operation
of DHCP does not depend on the transmission of DHCPRELEASE messages.
5. Pengakuan
The author thanks the many (and too numerous to mention!) members of
the DHC WG for their tireless and ongoing efforts in the development
of DHCP and this document.
The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
Mendonca in organizing DHCP interoperability testing sessions are
gratefully acknowledged.
The development of this document was supported in part by grants from
the Corporation for National Research Initiatives (CNRI), Bucknell
University and Sun Microsystems.
6. Referensi
[1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December
1983.
[2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
University, October 1993.
[3] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, USC/Information Sciences
Institute, October 1989.
[4] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support, STD 3, RFC 1123, USC/Information
Sciences Institute, October 1989.
[5] Brownell, D, "Dynamic Reverse Address Resolution Protocol
(DRARP)", Work in Progress.
[6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
Communications Review), 20(4):50--59, 1990.
[7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
Stanford and SUN Microsystems, September 1985.
[8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
PARC, September 1991.
[9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534,
Bucknell University, October 1993.
[10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
Address Resolution Protocol", RFC 903, Stanford, June 1984.
[11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant
Mechanism for Distributed File Cache Consistency", In Proc. of
the Twelfth ACM Symposium on Operating Systems Design, 1989.
[12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[13] Mockapetris, P., "Domain Names -- Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
Hosts", Work in Progress.
[16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
USC/Information Sciences Institute, September 1981.
[17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
USC/Information Sciences Institute, August 1993.
[18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
USC/Information Sciences Institute, October 1994.
[19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
Assignment of IP Addresses for use on an Ethernet. (Available
from the Athena Project, MIT), 1989.
[20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC,
June 1981.
[21] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, Carnegie Mellon University, October 1993.
7. Pertimbangan Keamanan
DHCP is built directly on UDP and IP which are as yet inherently
insecure. Furthermore, DHCP is generally intended to make
maintenance of remote and/or diskless hosts easier. While perhaps
not impossible, configuring such hosts with passwords or keys may be
difficult and inconvenient. Therefore, DHCP in its current form is
quite insecure.
Unauthorized DHCP servers may be easily set up. Such servers can
then send false and potentially disruptive information to clients
such as incorrect or duplicate IP addresses, incorrect routing
information (including spoof routers, etc.), incorrect domain
nameserver addresses (such as spoof nameservers), and so on.
Clearly, once this seed information is in place, an attacker can
further compromise affected systems.
Malicious DHCP clients could masquerade as legitimate clients and
retrieve information intended for those legitimate clients. Di mana
dynamic allocation of resources is used, a malicious client could
claim all resources for itself, thereby denying resources to
legitimate clients.
8. Author's Alamat
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (717) 524-1145
EMail: droms@bucknell.edu
A. Host Configuration Parameters
IP-layer_parameters,_per_host:_
Be a router on/off HRC 3.1
Non-local source routing on/off HRC 3.3.5
Policy filters for
non-local source routing (list) HRC 3.3.5
Maximum reassembly size integer HRC 3.3.2
Default TTL integer HRC 3.2.1.7
PMTU aging timeout integer MTU 6.6
MTU plateau table (list) MTU 7
IP-layer_parameters,_per_interface:_
IP address (address) HRC 3.3.1.6
Subnet mask (address mask) HRC 3.3.1.6
MTU integer HRC 3.3.3
All-subnets-MTU on/off HRC 3.3.3
Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6
Perform mask discovery on/off HRC 3.2.2.9
Be a mask supplier on/off HRC 3.2.2.9
Perform router discovery on/off RD 5.1
Router solicitation address (address) RD 5.1
Default routers, list of:
router address (address) HRC 3.3.1.6
preference level integer HRC 3.3.1.6
Static routes, list of:
destination (host/subnet/net) HRC 3.3.1.2
destination mask (address mask) HRC 3.3.1.2
type-of-service integer HRC 3.3.1.2
first-hop router (address) HRC 3.3.1.2
ignore redirects on/off HRC 3.3.1.2
PMTU integer MTU 6.6
perform PMTU discovery on/off MTU 6.6
Link-layer_parameters,_per_interface:_
Trailers on/off HRC 2.3.1
ARP cache timeout integer HRC 2.3.2.1
Ethernet encapsulation (RFC 894/RFC 1042) HRC 2.3.3
TCP_parameters,_per_host:_
TTL integer HRC 4.2.2.19
Keep-alive interval integer HRC 4.2.3.6
Keep-alive data size 0/1 HRC 4.2.3.6
Kunci:
MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
RD = Router Discovery (RFC 1256, Proposed Standard)
