Selama bertahun-tahun pers telah menulis tentang masalah yang sekarang ada sangat sedikit alamat IPv4 yang tersedia. Tetapi di sisi lain, saya menggunakan perusahaan hosting server yang dengan senang hati memberikan alamat IPv4 publik untuk sejumlah kecil uang. Dan koneksi internet pribadi saya dilengkapi dengan alamat IPv4 publik.

Bagaimana mungkin? Apakah masalahnya seburuk pers yang ingin kita percayai?

Sangat buruk. Berikut adalah daftar contoh dari apa yang saya alami pengalaman dengan ISP konsumen lakukan untuk mengatasi kekurangan alamat IPv4:

• Berkali-kali di sekitar blok IPv4 antar kota menyebabkan pemadaman singkat dan koneksi ulang bagi pelanggan.
• Mempersingkat waktu sewa DHCP dari hari ke menit.
• Izinkan pengguna untuk memilih apakah mereka menginginkan terjemahan alamat jaringan (NAT) pada Peralatan Pelanggan Premis (CPE) atau tidak, lalu tetap aktifkan untuk semua orang.
• Mengaktifkan NAT pada CPE untuk pelanggan yang sudah menggunakan kesempatan untuk memilih keluar dari NAT.
• Mengurangi tutup pada sejumlah alamat kontrol akses media aktif (MAC) yang diberlakukan oleh CPE.
• Menerapkan carrier-grade NAT (CGN) untuk pelanggan yang memiliki alamat IP asli ketika mereka mendaftar untuk layanan ini.

Semua ini mengurangi kualitas produk yang dijual ISP kepada pelanggan mereka. Satu-satunya penjelasan yang masuk akal untuk mengapa mereka melakukan ini kepada pelanggan mereka adalah kekurangan alamat IPv4.

Kekurangan alamat IPv4 telah menyebabkan fragmentasi ruang alamat yang memiliki beberapa kekurangan:

• Biaya administrasi yang tidak hanya menghabiskan waktu dan uang, tetapi juga rawan kesalahan dan menyebabkan pemadaman.
• Penggunaan besar kapasitas memory addressable memory (CAM) pada router backbone yang beberapa tahun yang lalu menyebabkan pemadaman yang signifikan di beberapa ISP ketika melewati batas model router populer tertentu.

Tanpa NAT, tidak ada cara yang bisa kita lakukan hari ini dengan 3700 juta alamat IPv4 yang dapat dirutekan. Tetapi NAT adalah solusi rapuh yang memberi Anda konektivitas yang kurang andal dan masalah yang sulit di-debug. Semakin banyak lapisan NAT akan semakin buruk. Kerja keras selama dua dekade telah membuat sebagian besar lapisan NAT berfungsi, tetapi kami telah melewati titik di mana satu lapis NAT cukup untuk mengatasi kekurangan alamat IPv4.

Sebelum kami mulai kehabisan alamat IPv4, kami tidak (secara luas) menggunakan NAT. Setiap komputer yang terhubung internet akan memiliki alamat uniknya sendiri secara global. Ketika NAT pertama kali diperkenalkan, itu adalah untuk beralih dari memberi pelanggan 1 alamat asli per perangkat pelanggan yang digunakan / dimiliki untuk memberikan 1 pelanggan 1 alamat asli. Itu memperbaiki masalah untuk sementara waktu (tahun) sementara kami seharusnya beralih ke IPv6. Alih-alih beralih ke IPv6, (kebanyakan) semua orang menunggu orang lain untuk beralih dan jadi (kebanyakan) tidak ada yang meluncurkan IPv6. Sekarang kita menghadapi masalah yang sama lagi, tetapi kali ini, lapisan kedua NAT sedang digunakan (CGN) sehingga ISP dapat berbagi 1 alamat nyata antara banyak pelanggan.

Kelelahan alamat IP bukanlah masalah besar jika NAT tidak mengerikan, termasuk dalam kasus di mana pengguna akhir tidak memiliki kendali atasnya (Carrier Grade NAT atau CGN).

Tetapi saya berpendapat bahwa NAT itu mengerikan, terutama dalam kasus di mana pengguna akhir tidak memiliki kendali atasnya. Dan (sebagai orang yang pekerjaannya adalah rekayasa jaringan / administrasi tetapi memiliki gelar rekayasa perangkat lunak) saya berpendapat bahwa dengan menggunakan NAT alih-alih IPv6, administrator jaringan telah mengalihkan bobot penyelesaian kelelahan alamat dari bidangnya dan ke pengguna akhir. dan pengembang aplikasi.

Jadi (menurut saya), mengapa NAT itu hal yang mengerikan dan jahat yang harus dihindari?

Mari kita lihat apakah saya bisa melakukannya dengan adil dalam menjelaskan apa yang rusak (dan masalah apa yang menyebabkannya sehingga kita menjadi terbiasa sehingga kita bahkan tidak menyadari itu bisa lebih baik):

• Independensi lapisan jaringan
• Koneksi peer to peer
• Penamaan dan lokasi sumber daya yang konsisten
• Routing optimal dari traffic, host mengetahui alamat asli mereka
• Melacak sumber lalu lintas berbahaya
• Protokol jaringan yang memisahkan data dan mengontrol ke dalam koneksi yang terpisah

Mari kita lihat apakah saya bisa menjelaskan masing-masing item itu.

Independensi lapisan jaringan

ISP seharusnya hanya melewati paket layer 3 dan tidak peduli apa yang ada di layer di atas itu. Apakah Anda melewati TCP, UDP, atau sesuatu yang lebih baik / lebih eksotis (SCTP mungkin? Atau bahkan beberapa protokol lain yang lebih baik daripada TCP / UDP, tetapi tidak jelas karena kurangnya dukungan NAT), ISP Anda tidak seharusnya peduli; itu semua hanya terlihat seperti data bagi mereka.

Tapi tidak - tidak ketika mereka menerapkan "gelombang kedua" NAT, "Carrier Grade" NAT. Maka mereka harus melihat, dan mendukung, protokol layer 4 yang ingin Anda gunakan. Saat ini, itu berarti Anda hanya dapat menggunakan TCP dan UDP. Protokol lain hanya akan diblokir / dijatuhkan (sebagian besar kasus dalam pengalaman saya) atau hanya diteruskan ke host terakhir "di dalam" NAT yang menggunakan protokol itu (saya telah melihat 1 implementasi yang melakukan ini). Bahkan meneruskan ke host terakhir yang menggunakan protokol itu bukanlah perbaikan nyata - begitu dua host menggunakannya, protokol itu rusak.

Saya membayangkan ada beberapa protokol pengganti untuk TCP & UDP di luar sana yang saat ini tidak diuji dan tidak digunakan hanya karena masalah ini. Jangan salah paham, TCP & UDP dirancang dengan sangat baik dan menakjubkan bagaimana keduanya bisa meningkatkan cara kita menggunakan internet saat ini. Tapi siapa yang tahu apa yang kita lewatkan? Saya sudah membaca tentang SCTP dan kedengarannya bagus, tetapi tidak pernah menggunakannya karena tidak praktis karena NAT.

Koneksi antar teman

Ini yang besar. Sebenarnya, yang terbesar menurut saya. Jika Anda memiliki dua pengguna akhir, keduanya di belakang NAT mereka sendiri, tidak peduli mana yang mencoba terhubung terlebih dahulu, NAT pengguna lain akan menjatuhkan paket mereka dan koneksi tidak akan berhasil.

Ini memengaruhi game, obrolan suara / video (seperti Skype), hosting server Anda sendiri, dll.

Ada beberapa solusi. Masalahnya adalah bahwa penyelesaian tersebut menghabiskan waktu pengembang, waktu pengguna akhir & ketidaknyamanan, atau biaya infrastruktur layanan. Dan mereka tidak mudah dan kadang-kadang rusak. (Lihat komentar pengguna lain tentang pemadaman yang diderita oleh Skype.)

Salah satu solusinya adalah penerusan port, di mana Anda memprogram perangkat NAT untuk meneruskan port masuk spesifik ke komputer tertentu di belakang perangkat NAT. Ada seluruh situs web yang ditujukan untuk melakukan hal ini untuk semua perangkat NAT berbeda yang ada di luar sana. Lihat https://portforward.com/ . Ini biasanya menghabiskan waktu dan frustrasi pengguna akhir.

Solusi lain adalah menambahkan dukungan untuk hal-hal seperti hole hole pada aplikasi, dan memelihara infrastruktur server yang tidak berada di belakang NAT untuk memperkenalkan dua klien NATed. Ini biasanya menghabiskan waktu pengembangan, dan menempatkan pengembang dalam posisi berpotensi memelihara infrastruktur server yang sebelumnya tidak diperlukan.

(Ingat apa yang saya katakan tentang penggunaan NAT alih-alih IPv6 yang mengalihkan beban masalah dari administrator jaringan ke pengguna akhir dan pengembang aplikasi?)

Penamaan / lokasi sumber daya jaringan yang konsisten

Karena ruang alamat yang berbeda digunakan di bagian dalam NAT kemudian di luar, setiap layanan yang ditawarkan oleh perangkat di dalam NAT memiliki beberapa alamat untuk mencapainya, dan yang benar untuk digunakan tergantung pada tempat klien mengaksesnya dari . (Ini masih menjadi masalah bahkan setelah port forwarding berfungsi.)

Jika Anda memiliki server web di dalam NAT, katakan pada port 192.168.0.23 port 80, dan perangkat NAT Anda (router / gateway) memiliki alamat eksternal 35.72.216.228, dan Anda mengatur penerusan port untuk port TCP 80, sekarang Anda server web dapat diakses dengan menggunakan port 192.168.0.23 port 80 ATAU 35.72.216.228 port 80. Yang harus Anda gunakan tergantung pada apakah Anda berada di dalam atau di luar NAT. Jika Anda berada di luar NAT, dan menggunakan alamat 192.168.0.23, Anda tidak akan sampai ke tempat yang Anda harapkan. Jika Anda berada di dalam NAT, dan Anda menggunakan alamat eksternal 35.72.216.228, Anda mungkin mendapatkan di mana Anda ingin, jika implementasi NAT Anda adalah yang canggih yang mendukung jepit rambut, tetapi kemudian server web yang melayani permintaan Anda akan melihat permintaan tersebut berasal dari perangkat NAT Anda. Ini berarti bahwa semua lalu lintas harus melalui perangkat NAT, bahkan jika ada jalur yang lebih pendek di jaringan di belakang NAT, dan itu berarti bahwa log pada server web menjadi jauh lebih tidak berguna karena mereka semua mendaftar perangkat NAT sebagai sumber koneksi. Jika implementasi NAT Anda tidak mendukung jepit rambut, maka Anda tidak akan mendapatkan tujuan yang Anda tuju.

Dan masalah ini semakin memburuk segera setelah Anda menggunakan DNS. Tiba-tiba, jika Anda ingin semuanya berfungsi dengan baik untuk sesuatu yang dihosting di belakang NAT, Anda akan ingin memberikan jawaban berbeda pada alamat layanan yang dihosting di dalam NAT, berdasarkan pada siapa yang bertanya (AKA split horizon DNS, IIRC). Yuck.

Dan itu semua dengan asumsi Anda memiliki seseorang yang berpengetahuan tentang port forwarding dan hairpin NAT dan membagi cakrawala DNS. Bagaimana dengan pengguna akhir? Apa peluang mereka untuk mengatur semua ini dengan benar ketika mereka membeli router konsumen dan beberapa kamera keamanan IP dan ingin "hanya bekerja"?

Dan itu menuntun saya ke:

Routing optimal dari traffic, host mengetahui alamat asli mereka

Seperti yang telah kita lihat, bahkan dengan hairpin canggih, lalu lintas NAT tidak selalu mengalir melalui jalur yang optimal. Itu bahkan dalam kasus di mana administrator yang berpengetahuan membuat server dan memiliki hairpin NAT. (Diberikan, DNS split horizon dapat menyebabkan perutean lalu lintas internal yang optimal di tangan administrator jaringan.)

Apa yang terjadi ketika pengembang aplikasi membuat program seperti Dropbox, dan mendistribusikannya kepada pengguna akhir yang tidak berspesialisasi dalam mengkonfigurasi peralatan jaringan? Secara khusus, apa yang terjadi ketika saya meletakkan file 4GB di file share saya, dan kemudian mencoba mengaksesnya di komputer berikutnya? Apakah itu langsung mentransfer antar mesin, atau apakah saya harus menunggu untuk mengunggah ke server cloud melalui koneksi WAN yang lambat, dan kemudian menunggu untuk kedua kalinya untuk mengunduh melalui koneksi WAN lambat yang sama?

Untuk implementasi yang naif, itu akan diunggah dan kemudian diunduh, menggunakan infrastruktur server Dropbox yang tidak berada di belakang NAT sebagai mediator. Tetapi jika kedua mesin hanya dapat menyadari bahwa mereka berada di jaringan yang sama, maka mereka bisa langsung mentransfer file lebih cepat. Jadi untuk implementasi pertama yang kurang naif kami coba, kami mungkin bertanya kepada OS apa alamat IP (v4) yang dimiliki mesin, dan kemudian memeriksa terhadap mesin lain yang terdaftar di akun Dropbox yang sama. Jika berada dalam kisaran yang sama dengan kami, langsung saja transfer file. Itu mungkin berhasil dalam banyak kasus. Tetapi meskipun ada masalah: NAT hanya berfungsi karena kita dapat menggunakan kembali alamat. Jadi bagaimana jika alamat 192.168.0.23 dan 192.168.0. 42 alamat yang terdaftar di akun Dropbox yang sama sebenarnya di jaringan yang berbeda (seperti jaringan rumah Anda dan jaringan kerja Anda)? Sekarang Anda harus gagal kembali menggunakan infrastruktur server Dropbox untuk menengahi. (Pada akhirnya, Dropbox mencoba menyelesaikan masalah dengan meminta setiap klien Dropbox menyiarkan di jaringan lokal dengan harapan menemukan klien lain. Tetapi siaran itu tidak melewati router apa pun yang mungkin Anda miliki di belakang NAT, artinya itu bukan solusi lengkap ,khususnya dalam kasus CGN .)

IP statis

Selain itu, sejak kekurangan pertama (dan gelombang NAT) terjadi ketika banyak koneksi konsumen tidak selalu pada koneksi (seperti dialup), ISP dapat menggunakan alamat mereka dengan lebih baik dengan hanya mengalokasikan alamat IP publik / eksternal ketika Anda benar-benar terhubung. Itu berarti bahwa ketika Anda terhubung, Anda mendapatkan alamat apa pun yang tersedia, daripada selalu mendapatkan alamat yang sama. Itu membuat menjalankan server Anda sendiri jauh lebih sulit, dan itu membuat pengembangan aplikasi peer to peer lebih sulit karena mereka perlu berurusan dengan rekan-rekan yang bergerak alih-alih berada di alamat tetap.

Kebingungan dari sumber lalu lintas berbahaya

Karena NAT menulis ulang koneksi keluar menjadi seolah-olah mereka berasal dari perangkat NAT itu sendiri, semua perilaku, baik atau buruk, digulung menjadi satu alamat IP eksternal. Saya belum melihat perangkat NAT yang mencatat setiap koneksi keluar secara default. Ini berarti bahwa secara default, sumber lalu lintas berbahaya masa lalu hanya dapat dilacak ke perangkat NAT yang dilaluinya. Sementara peralatan perusahaan atau kelas operator yang lebih banyak dapat dikonfigurasi untuk mencatat setiap koneksi keluar, saya belum melihat ada router konsumen yang melakukannya. Saya tentu berpikir akan menarik untuk melihat apakah (dan untuk berapa lama) ISP akan menyimpan log semua koneksi TCP dan UDP yang dibuat melalui CGNs saat mereka meluncurkannya. Catatan seperti itu akan diperlukan untuk menangani keluhan penyalahgunaan dan keluhan DMCA.

Beberapa orang berpikir bahwa NAT meningkatkan keamanan. Jika ya, itu dilakukan melalui ketidakjelasan. Penurunan standar lalu lintas masuk yang dibuat NAT adalah wajib sama dengan memiliki firewall stateful. Ini adalah pemahaman saya bahwa setiap perangkat keras yang mampu melakukan pelacakan koneksi yang diperlukan untuk NAT harus dapat menjalankan firewall stateful, jadi NAT tidak benar-benar layak mendapatkan poin di sana.

Protokol yang menggunakan koneksi kedua

Protokol seperti FTP dan SIP (VoIP) cenderung menggunakan koneksi terpisah untuk kontrol dan konten data aktual. Setiap protokol yang melakukan ini harus memiliki perangkat lunak pembantu yang disebut ALG (application layer gateway) pada setiap perangkat NAT yang dilaluinya, atau mengatasi masalah dengan beberapa jenis mediator atau hole punch. Dalam pengalaman saya, ALG jarang jika pernah diperbarui dan telah menjadi penyebab setidaknya beberapa masalah yang saya hadapi dengan melibatkan SIP. Setiap kali saya mendengar seseorang melaporkan bahwa VoIP tidak berfungsi untuk mereka karena audio hanya bekerja satu arah, saya langsung curiga bahwa di suatu tempat, ada gateway NAT yang menjatuhkan paket UDP yang tidak dapat mengetahui apa yang harus dilakukan.

Singkatnya, NAT cenderung pecah:

• protokol alternatif untuk TCP atau UDP
• sistem peer-to-peer
• mengakses sesuatu yang dihosting di belakang NAT
• hal-hal seperti SIP dan FTP. ALG untuk mengatasi ini masih menyebabkan masalah acak dan aneh saat ini, terutama dengan SIP.

Pada intinya, pendekatan berlapis yang diambil tumpukan jaringan relatif sederhana dan elegan. Cobalah untuk menjelaskannya kepada seseorang yang baru mengenal jaringan, dan mereka pasti menganggap jaringan rumah mereka mungkin adalah jaringan yang baik dan sederhana untuk dipahami. Saya telah melihat petunjuk ini dalam beberapa kasus dengan beberapa ide yang cukup menarik (sangat rumit) tentang bagaimana perutean bekerja karena kebingungan antara alamat eksternal dan internal.

Saya menduga bahwa tanpa NAT, VoIP akan ada di mana-mana dan terintegrasi dengan PSTN, dan bahwa membuat panggilan dari ponsel atau komputer akan gratis (kecuali untuk internet yang sudah Anda bayar). Lagi pula, mengapa saya harus membayar untuk telepon ketika Anda dan saya hanya dapat membuka aliran VoIP 64K dan berfungsi seperti halnya PSTN? Sepertinya hari ini, masalah nomor 1 dengan penyebaran VoIP akan melalui perangkat NAT.

Saya menduga kita biasanya tidak menyadari betapa banyak hal yang lebih sederhana jika kita memiliki konektivitas ujung ke ujung yang dipatahkan NAT. Orang-orang masih mengirim email (atau Dropbox) sendiri file karena jika masalah inti membutuhkan mediator ketika dua klien berada di belakang NAT.

Satu gejala besar dari kelelahan IPv4 yang saya tidak lihat disebutkan dalam jawaban lain adalah bahwa beberapa penyedia layanan seluler mulai menggunakan IPv6-hanya beberapa tahun yang lalu. Ada kemungkinan Anda telah menggunakan IPv6 selama bertahun-tahun dan bahkan tidak mengetahuinya. Penyedia seluler lebih baru untuk gim Internet, dan tidak harus memiliki alokasi IPv4 besar yang sudah ada untuk menarik. Mereka juga memerlukan lebih banyak alamat daripada kabel / DSL / serat, karena ponsel Anda tidak dapat berbagi alamat IP publik dengan anggota rumah tangga lainnya.

Dugaan saya adalah penyedia IaaS dan PaaS akan menjadi yang berikutnya, karena pertumbuhan mereka yang tidak terkait dengan alamat fisik pelanggan. Saya tidak akan terkejut melihat penyedia IaaS menawarkan IPv6 hanya dengan diskon segera.

RIR utama kehabisan ruang untuk alokasi normal beberapa waktu lalu. Oleh karena itu bagi sebagian besar penyedia, satu-satunya sumber alamat IPv4 adalah simpanan mereka sendiri dan pasar.

Ada beberapa skenario di mana lebih disukai untuk memiliki IP IP4 publik publik yang berdedikasi tetapi itu tidak sepenuhnya penting. Ada juga banyak alamat IPv4 publik yang dialokasikan tetapi saat ini tidak digunakan di internet publik (mereka mungkin digunakan di jaringan pribadi atau mereka mungkin tidak digunakan sama sekali). Akhirnya ada jaringan yang lebih tua dengan alamat yang dialokasikan jauh lebih longgar dari yang seharusnya.

Tiga RIR terbesar sekarang memungkinkan alamat untuk dijual antara anggota mereka dan satu sama lain anggota. Jadi kami memiliki pasar antara organisasi yang memiliki alamat yang tidak mereka gunakan atau yang memiliki alamat yang dapat dibebaskan dengan biaya di satu sisi dan organisasi yang benar-benar membutuhkan lebih banyak alamat IP di sisi lain.

Apa yang sulit diprediksi adalah berapa banyak penawaran dan permintaan akan ada pada setiap titik harga dan karenanya apa yang akan dilakukan harga pasar di masa depan. Sejauh ini harga per IP tampaknya tetap rendah.

Idealnya, setiap host di internet harus dapat memperoleh alamat IP lingkup global, namun kelelahan alamat IPv4 adalah nyata, infact ARIN sudah kehabisan alamat di pool gratis mereka .

Alasan mengapa semua orang masih dapat mengakses layanan internet dengan baik, adalah berkat teknik Network Address Translation (NAT) yang memungkinkan banyak host berbagi alamat IP publik. Namun, ini tidak datang tanpa masalah.

ISP biasa memberikan blok 256 alamat IP ke perusahaan. Sekarang, ISP pelit dan memberi Anda (perusahaan) seperti 5. Kembali pada hari (2003), setiap PC dan perangkat yang terhubung di rumah Anda memiliki alamat IP internet sendiri. Sekarang, router kabel / DSN / Fios memiliki satu alamat IP dan memberikan alamat IP 10.0.0.x ke semua PC di rumah Anda. Ringkasan: ISP dulu membuang-buang alamat IP dan sekarang mereka tidak menyia-nyiakannya lagi.

Anda sudah mendapatkan banyak jawaban bagus, tetapi saya ingin menambahkan sesuatu yang belum disebutkan.

Ya, kelelahan alamat IPv4 buruk, tergantung pada bagaimana Anda mengukurnya. Beberapa perusahaan masih memiliki persediaan alamat IPv4 yang sangat besar, tetapi kami mulai melihat solusi seperti NAT tingkat operator.

Tetapi banyak dari jawaban yang salah ketika mereka beralih ke IPv6.

Berikut adalah daftar teknologi yang dapat membantu menangani kekurangan alamat IPv4. Masing-masing memiliki kelebihan dan kekurangannya sendiri.

• IPv6

  • Keuntungan: terstandarisasi dan tersedia di sebagian besar sistem operasi.
  • Kelemahan: meskipun sering pernyataan sebaliknya, masalah keamanan serius. Sejauh 2005, US CERT memperingatkan masalah keamanan yang disebabkan oleh pengalamatan global IPv6. IPv6 dapat diamankan dengan benar, tetapi mengingat keadaan router konsumen, itu mungkin tidak terjadi.
  • Kelemahan: migrasi membutuhkan waktu, uang, dan keahlian.
  • Kelemahan: banyak perangkat tingkat konsumen yang cacat serius. Misalnya, sejumlah router D-Link mendukung IPv6 dengan hanya meneruskan semua lalu lintas tanpa menawarkan firewall apa pun.

Pertimbangan lain: bahkan jika IPv6 benar-benar digunakan hari ini, masih akan memakan waktu 20 tahun lagi untuk menghapus IPv4, karena peralatan warisan yang akan digunakan orang untuk waktu yang sangat lama (saya masih melihat server Windows 2003 dan workstation Windows XP kadang-kadang! Belum lagi semua printer dan kamera serta gadget IoT yang tidak mendukung IPv6).

• CGNat:
  • Keuntungan: bekerja tanpa perubahan di lokasi pelanggan.
  • Kelemahan: hanya mendukung koneksi keluar.
  • Kelemahan: mungkin tidak mendukung beberapa protokol.

Akhirnya, CGNat tidak akan cukup. Mungkin IPv6 akan populer, tetapi juga sangat mungkin bahwa kita akhirnya akan melihat NAT tingkat negara, atau sesuatu seperti itu.

Saat ini, sebagai konsultan, saya sering harus menunjukkan kepada pelanggan saya bahwa mereka terpapar pada IPv6 (sering terima kasih kepada Teredo). Pertanyaan selanjutnya akan selalu: "berapa biaya untuk memperbaikinya?" dan kemudian "Berapa biaya untuk memblokirnya? Apa ruginya jika kita mematikannya?" Tebak keputusan apa yang akan diambil setiap saat.

Intinya: untuk menjawab pertanyaan Anda, ya, kelelahan IPv4 adalah nyata. Dan kita akan melihat beberapa mekanisme untuk mengatasinya. IPv6 mungkin atau mungkin tidak menjadi persamaan.

Untuk lebih jelasnya: Saya tidak mengatakan bahwa saya menyukai situasi ini. Saya ingin IPv6 berhasil (dan saya ingin melihat sejumlah peningkatan IPv6). Saya hanya melihat situasi seperti saat ini.

NAT adalah apa yang terjadi ketika IPv6 adalah sebuah ide, sebelum itu kenyataan, dan alokasi alamat IP menjadi masalah nyata (ada yang ingat ketika mereka membagi-bagikan Kelas C pada dasarnya untuk bertanya?) Dan dunia nyata membutuhkan solusi sementara itu .

NAT tidak cukup untuk IoT. Jika IoT akan terjadi, itu akan terjadi dengan IPv6. Sifat IoT lebih selaras dengan bagaimana dunia dialup bekerja, kecuali bahwa akan ada beberapa urutan besarnya lebih banyak perangkat yang terhubung pada saat yang sama.

Seluruh masalah alamat IPv4 agak berbelit-belit. Anda mungkin menemukan artikel tertentu melaporkannya sudah habis, yang lain berbicara tentang sejumlah besar surplus (tidak pernah digunakan) alamat yang dijual dari satu pihak ke pihak lain. Pertanyaannya adalah mengapa ini tidak tersedia bagi mereka (daerah yang muncul dan daerah pedesaan di negara maju) kekurangan mereka?

Di bawah ini adalah hasil penelitian yang secara tidak sengaja kami jelajahi. Ini menggunakan tidak lebih dari protokol IPv4 RFC791 asli dan blok alamat 240/4 lama dicadangkan tetapi hampir tidak digunakan untuk memperluas kolam IPv4 dengan 256 juta kali lipat. Kami telah mengirimkan rancangan proposal yang disebut EzIP (fonetik untuk Easy IPv4) ke IETF:

https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03

Pada dasarnya, pendekatan EzIP tidak hanya akan menyelesaikan masalah kekurangan alamat IPv4, tetapi juga sebagian besar mengurangi akar penyebab kerentanan keamanan cyber, plus membuka kemungkinan baru untuk Internet, semua dalam batas-batas domain IPv4. Bahkan, skema ini dapat digunakan "diam-diam" untuk daerah terpencil di mana diperlukan. Ini harus meringankan urgensi untuk menggunakan IPv6 untuk waktu yang cukup lama, dan membatalkan pasar perdagangan alamat IPv4.

Setiap pemikiran atau komentar akan sangat dihargai.

Abe (2018-07-15 17:29)

Jujur, saya pikir itu tidak seburuk yang dipikirkan orang. Ya, mungkin di beberapa tempat, tetapi tidak terlalu banyak karena tidak ada alamat yang cukup. Itu karena mereka semua dimiliki. Mungkin itu lokasi saya atau sesuatu, tapi saya sudah melakukan pekerjaan TI untuk sekelompok usaha kecil hingga menengah dalam tujuh tahun terakhir, dan semua hal yang Anda bicarakan biasanya hanya pengaturan standar. Cukup mudah kecuali jika Anda memiliki perangkat jelek, atau ada pengaturan buruk dengan jaringan di tempat pertama yang perlu diselesaikan.

Secara pribadi, saya baik-baik saja dengan NAT. Ini lapisan perlindungan tambahan, secara umum. Setidaknya mereka harus melalui perangkat tambahan, atau menemukan cara untuk secara tidak langsung membajak koneksi saya. Sejauh menjalankan server, itu umumnya di luar dan / atau dianggap sebagai pelanggaran kontrak dengan ISP Anda kecuali Anda membayar untuk itu. Tentu Anda bisa melakukannya, dan mereka mungkin tidak akan mengganggumu, tetapi mereka bisa.

Port-forwarding dan semua itu tidak persis rumit. Sekarang, mungkin beberapa perangkat tidak mudah dikonfigurasi, tetapi itu bukan karena IPv4. Itu masih menawarkan kompatibilitas yang paling hanya karena itu ada di mana-mana.

Tidak ada yang benar-benar perlu mengirim email kepada diri mereka sendiri, dan mengirim sesuatu ke Drop-box atau Google Drive, atau jutaan layanan serupa lainnya bukanlah ilmu roket, atau lambat, akhir-akhir ini. Maksud saya semuanya sinkron. Anda menjatuhkannya di folder. Kecuali Anda kutu buku seperti saya, dan Anda melakukan segalanya melalui ssh / sftp (oke bukan segalanya ). Dan jika Anda memiliki alasan mengapa Anda benar-benar ingin menjalankan server Anda sendiri, cloud hosting itu murah - Saya punya server virtual khusus yang menjalankan linux pada SSD. Bandwidth cepat gila. Ini mem-boot lebih cepat daripada saya bisa mengetikkan panah atas dan tekan Enter. Dan scalable Seluruh biaya setup antara 5 dan 10 dolar sebulan, dengan cadangan gratis dan tanpa tagihan listrik.

Tidak benar-benar membutuhkan solusi peer-network. Bahkan sebagian besar permainan multi-pengguna hari ini adalah semua pengaturan untuk berinteraksi melalui server yang mengintervensi, semua pengaturan dan konfigurasi awal. Di sisi lain, jika apa yang saya baca di posting ini benar, IT akan penuh sesak dan murah jika IPv6 lepas landas. Bahkan ponsel mendekati kecepatan seperti serat. Atau setidaknya kabel.

Jika Anda menjalankan server in-house, dan Anda perlu menekannya dengan nama domain yang sama di dalam atau di luar jaringan Anda, Anda selalu dapat menipu alamatnya menggunakan router berbasis linux dan dnsmasq atau apa pun dan entri khusus di host file untuk mengarahkan Anda ke alamat lokal jika Anda berada di dalam.

Sungguh, saya tidak berpikir itu sebenarnya diinginkan untuk memiliki setiap perangkat memiliki alamat sendiri langsung di luar sana mengambang terbuka di internet. Jika seseorang ingin mengaburkan diri mereka sendiri saat menyerang Anda, itu akan terjadi bagaimanapun juga. Tapi Anda bebek duduk jika Anda hanya duduk di sana bola di angin terbuka. Nah, saya akan mengambil IPv4 dan NAT saya kapan saja. Tapi ada baiknya itu ada di sana.

Anywa, tertidur sekarang ... mungkin lebih banyak bicara tapi aku akan check in besok kalau-kalau aku melewatkan sesuatu. Saya yakin masih ada lagi.