Mengapa Anda memerlukan Permohonan Neighbor IPv6 untuk mendapatkan alamat MAC?

Saya seorang pengembang perangkat lunak dan baru saja mendapatkan buku gratis tentang IPv6 di Techdays, yang saya baca untuk bersenang-senang. Mereka memberikannya karena itu sedikit buku tua (W2008), jadi mungkin hal-hal berbeda untuk OS lain / yang lebih baru, tapi saya tidak mengerti perlunya Neighbor Discovery untuk mendapatkan alamat MAC.

Menurut buku itu, setiap node secara otomatis mendapatkan alamat IP lokal-Tautan, yang dibangun dari alamat MAC dengan memasukkan FF-FEantara 3 dan 4 byte dan membalik bit U / L, sehingga IP Tautan-lokal untuk simpul dengan alamat MAC 00-AA-00-3F-2A-1Cmenjadi FE80::2AA:FF:FE:3F:2A1C.

Untuk menentukan alamat MAC lapisan tautan, pesan Permintaan Tetangga dikirim ke alamat IP lokal-tautan, yang membalas dengan pesan yang berisi alamat MAC-nya ... Tetapi pengirim sudah tahu itu, karena MAC dikodekan dalam tautan- alamat IP lokal. Jadi sepertinya mengirim surat kepada seseorang yang menanyakan alamat mereka.

ipv6 discovery

— Edwin
sumber

Jawaban:

Setiap node secara otomatis menghasilkan alamat tautan-lokal, tetapi:

Alamat itu mungkin tidak dihasilkan dengan format EUI-64 yang ditentukan dalam RFC 2464 . Alamat IPv6 juga dapat berupa alamat yang dibuat secara kriptografis ( RFC 3972 ), alamat privasi sementara ( RFC 4941 ), atau dalam sistem operasi modern, alamat privasi stabil ( RFC 7217 ).
Alamat yang sepertinya memiliki ID antarmuka EUI-64 mungkin sebenarnya tidak sesuai dengan alamat MAC yang ditunjukkan karena konfigurasi eksplisit oleh administrator.

Karena Anda tidak bisa hanya "mengonversi alamat kembali" ke alamat MAC, Anda harus mengirim Permohonan Neighbor untuk menentukan alamat MAC.

Ada alasan lain mengapa Neighbor Solicitations juga diperlukan. Beberapa di antaranya adalah:

Deteksi alamat duplikat ( RFC 4862 ). Mungkin saja beberapa host lain mungkin (benar atau salah) mengklaim alamat yang ingin digunakan oleh host.
Deteksi unreachability tetangga. Kurangnya respons terhadap Permohonan Neighbor adalah salah satu indikator bahwa tetangga itu tidak terjangkau.

Buku-buku bagus dan bagus, tetapi buku-buku yang sangat ketinggalan zaman mungkin tidak begitu berguna. Bahkan IPv6 telah mengalami revisi signifikan dalam sepuluh tahun terakhir. Sumber kebenaran terbaik adalah RFC yang relevan, baik yang asli maupun yang ditandai telah diperbarui atau usang. RFC ditentukan secara cukup rinci untuk memungkinkan implementasi yang sesuai ditulis. Anda dapat mempelajari semua detail penemuan tetangga dengan membaca RFC 4861 .

— Michael Hampton
sumber

Terima kasih atas koreksinya; jika tidak menggunakan format EUI-64 memang ada kebutuhan untuk menemukan MAC sebaliknya. Tapi sebenarnya, saya tidak mengerti masalah privasi dengan format EUI-64 untuk alamat tautan-lokal, karena alamat tautan-lokal dicakup dalam tautan dan pada tautan itu, alamat MAC harus (dan dapat ) tetap dikenal (oleh Neighbor Solicitation) untuk komunikasi Ethernet, jadi untuk niat jahat, alamat MAC dapat disimpan di sepanjang alamat privasi stabil pada tautan lokal, bukan?

— Edwin

@ Edwin, SLAAC pada awalnya digunakan untuk semua pengalamatan IPv6, bukan hanya alamat Tautan-Lokal, sehingga sebuah host dapat dilacak. SLAAC hanya satu metode untuk menetapkan alamat Tautan-Lokal. Mereka juga dapat ditugaskan secara manual, dan itu tidak akan memberi Anda alamat MAC di alamat Tautan-Lokal. Saya tahu beberapa orang yang ingin menetapkan semua alamat secara manual, termasuk Tautan Lokal. Tampaknya banyak pekerjaan untuk sedikit atau tanpa hasil, tetapi itu membuat mereka senang, dan semua IID dari semua alamat pada sebuah antarmuka adalah sama, dalam urutan yang mereka sukai.

— Ron Maupin

@ Edwin Dan, setiap host memang akan mempertahankan Destination Cache (lihat RFC 4861), yang analog dengan tabel ARP IPv4 yang di-host-host.

— Michael Hampton

CGA bisa lebih sederhana dan lebih aman jika alamatnya dua kali ukurannya. Setengah spec adalah solusi untuk hanya memiliki 64 bit di pengenal antarmuka di mana mereka idealnya ingin sekitar 162 bit. Itu hal yang perlu diingat setiap kali gagasan bahwa 128 bit terlalu banyak muncul.

— kasperd

Apa yang Anda anggap tidak standar tentang dokumen Microsoft itu? Bagi saya sepertinya hanya merangkum RFC yang telah Anda tautkan.

— kasperd

Jadi, Anda salah paham atau salah informasi tentang beberapa hal.

Menggunakan SLAAC, sebuah host dapat membangun alamat IPv6nya sendiri menggunakan alamat MAC-nya, tetapi banyak orang berpikir bahwa ini berbahaya, memberikan terlalu banyak informasi, dan memungkinkan host tertentu untuk dilacak. Berdasarkan itu, ekstensi privasi dan pengalamatan acak dikembangkan, dan mereka digunakan oleh OS untuk memberikan privasi / keamanan. Itu berarti sebuah host dapat membuat pengalamatannya sendiri, bukan berdasarkan alamat MAC-nya.

Ketika sebuah host perlu menemukan alamat MAC dari tetangga di IPv4, ia menggunakan ARP. ARP menyiarkan permintaan, tetapi IPv6 tidak memiliki siaran. Sebagai gantinya, setiap host harus bergabung dengan grup multicast Node Solicited. Grup ini didasarkan pada 24 bit terakhir dari alamat IPv6-nya. Karena antarmuka IPv6 dapat memiliki sejumlah alamat IPv6, sebuah host dapat bergabung dengan beberapa grup multicast Node Solicited. Host IPv6 yang mencari alamat MAC dari host lain akan mengirimkan permintaan multicast ke grup multicast Node Solicited dari alamat IPv6 target.

Ini memberikan keuntungan dibandingkan IPv4 ARP. Karena ARP menggunakan siaran untuk permintaan, itu menginterupsi setiap host pada domain broadcast lapisan-2. Karena grup multicast Node Solicited menggunakan 24 bit terakhir dari alamat IPv6 target, permintaan multicast ND mungkin hanya akan mengganggu host target, atau mungkin satu atau dua host lain pada domain broadcast layer-2.

— Ron Maupin
sumber