Pengertian
Internet Versi Protokol 6 disingkat ke IPV6. Versi yang sebelumnya Internet Protokol adalah versi 4 ( dikenal sebagai IPV4).
IPV6 adalah suatu versi IP baru yang mana dirancang untuk;menjadi suatu langkah evolusiner dari IPV4. Ini merupakan suatu kenaikan alami ke IPV4. Ini dapat diinstall sebagai perangkat lunak yang dapat diupgrade normal di peralatan internet dan interoperable dengan IPV4 yang sekarang . Strategi Penyebaran nya dirancang untuk tidak mempunyai flagdays atau ketergantungan lainnya. IPV6 dirancang untuk menjalankan dengan baik pada jaringan capaian tinggi ( e.g. Gigabit Ethernet, OC-12, ATM, dll.) dan pada waktu yang sama tetap efisien untuk jaringan bandwitch rendah ( e.g. tanpa kawat). Sebagai tambahan, itu menyediakan suatu platform untuk internet kemampuan baru yang akan diperlukan di masa dekat mendatang.
IPV6 meliputi suatu mekanisme transisi yang mana dirancang untuk mengijinkan para pemakai untuk mengadopsi dan menyebar IPV6 di dalam menghamburkan pertunjukan yang tinggi dan untuk menyediakan interoperabilas langsung antara IPV4 dan IPV6 hosts. Transisi suatu versi baru Internet Protokol harus incremental, dengan sedikit atau tidak ada kritis interdependencies, jika itu adalah untuk berhasil. IPV6 transisi mengijinkan para pemakai [itu] untuk mengupgrade hosts mereka ke IPV6, dan operator jaringan untuk menyebar IPV6 di penerus, dengan sangat kecil koordinasi antara keduanya.
IPV6 Kelompok Kerja
IPV6 kelompok kerja adalah suatu IETF kelompok kerja mencarter untuk mengembangkan generasi yang berikutnya Internet Protokol. Kelompok kerja sebelumnya dinamai IP Next Generation Working Group (IPNGWG).
IPV6 kelompok kerja menghadirkan puncak dari banyak kelompok kerja di dalam IETF yang bekerja pada masalah routing dan masalah pengalamatan.
6Bone adalah IPV6 tulang punggung yang telah disediakan untuk membantu evolusi dan penyebaran IPV6 di Internet . 6Bone memulai sebagai konsep di tahun 1995 dan telah dibuat fondasi oleh suatu pertemuan pada Maret 1996 IETF yang bertemu Los Angeles. Sekarang ada site 6Bone di negara-negara di Asia, Australia Austria, Eropa, dan Amerika Utara. Semua 6Bone lokasi ditunjukkan pada 6Bone peta topologi. Kelompok kerja Transisi Generasi Yang berikutnya di IETF adalah bertanggung jawab untuk merancang mekanisme dan memeriksa prosedur untuk mendukung transisi Internet dari IPV4 ke IPV6.
6Ren adalah suatu prakarsa koordinasi Jaringan Pendidikan Dan Riset sukarela/fakultatif yang menyediakan produksi pemindahan IPV6 melayani untuk memudahkan mutu tinggi, performance yang tinggi, dan jaringan IPV6 secara operasional sempurna. Keikutsertaan bebas dan terbuka bagi semua Riset Dan Jaringan Pendidikan yang menyediakan IPV6 servis. Lain untuk keuntungan dan tidak untuk keuntungan IPV6 juga didukung untuk mengambil bagian.
Suatu gabungan yang meliputi seluruh dunia memimpin Penjual Internet, Riset& Jaringan Pendidikan sedang membentuk Forum IPV6 , dengan suatu misi jelas untuk mempromosikan IPV6 dengan secara dramatis meningkatkan kesadaran pemakai dan pasar IPV6 .
2.1.2 Pengembangan IPV6
- Perubahan dari IPV4 ke IPV6 terutama pada:
o Memperluas Kemampuan Pengalamatan
IPV6 meningkatkan alamat IP dari 32 bit - 128 bit, untuk
mendukung lebih banyak tingkatan dari pengalamatan hirarki, suatu jumlah yang lebih besar untuk pengalamatan nodes, dan auto-configuration yang lebih sederhana dari pengalamatan. Scalabilas multicast routing ditingkatkan dengan menambahkan sebuah " lingkup" bidang ke alamat multicast .Dan suatu jenis baru dari alamat disebut suatu " alamat anycast " digambarkan, digunakan untuk mengirimkansuatu paket kepada beberapa orang suatu kelompok .
o Penyederhanaan Format Header
Beberapa bidang header IPV4 telah dijatuhkan atau dibuat opsional, untuk mengurangi ongkos pemrosesan common case dari packet handling dan untuk membatasi ongkos bandwitch dari header IPV6.
o Meningkatkan support untuk perluasan dan pilihan
Merubah cara pilihan header IP disandikan mempertimbangkan penyampaian yang lebih efisien, lebih sedikit keras membatasi pada panjangnya pilihan, dan fleksibilitas lebih besar untuk memperkenalkan pilihan baru di masa datang.
o Mengalirkan Kemampuan Labeling
Suatu kemampuan baru ditambahkan untuk dapat melabelkan paket kepunyaan lalu lintas tertentu " arus" di mana pengirim meminta penanganan khusus, seperti kualitas yang tidak pasti dari servis atau ‘ real time’ service
o Pengesahan Dan Kemampuan Privasi.
Perluasan untuk mendukung pengesahan, integritas data, dan ( opsional) kerahasiaan data ditetapkan untuk IPV6.
2.1.3 Spesifikasi IPV6
Suatu daftar dari spesifikasi IPV6 secara umum diorganisasikan oleh fungsi. Daftar dari spesifikasi IPV6 oleh IETF Standardization Status
2.1.4 Implementasi IPV6
Implementasi IPV6 dikembangkan untuk banyak penerus dan sistem operasi host berbeda. Banyak yang sekarang mengirimkan produk. Ini meliputi implementasi host : Apple, BSDI, Bull, Digital, Epilogue, FreeBSD, FTP Software, Hitachi, HP, IBM, INRIA, Interpeak, Linux, Mentat, Microsoft, NetBSD, Nokia, Novell, NRL, NTHU, OpenBSD, Pacific Softworks, Process Software, SICS, SCO, Siemens Nixdorf, Silicon Graphics, Sun, UNH, and WIDE, and router implementations by 3Com, 6WIND, Bay Networks, cisco Systems, Digital, Hitachi, IBM, Merit (routing protocols), Nokia, NTHU, Sumitomo Electric, and Telebit Communications.
2.2 Istilah
Node : suatu alat yang mengimplementasikanIPV6.
Routes :suatu node yang ke depan paket IPV6 tidak dengan tegas yang menunjukkan dirinya sendiri.
Host : beberapa nodes yang bukan router.
Upper layer : suatu lapisan protokol yang dengan seketika di atas IPV6. Contoh :
protokol pengangkutan seperti TCP dan UDP, kendali protocol seperti ICMP, routing protokol seperti OSPF, dan internet atau lower-layer protokol menjadi " tunneled" atas ( yaitu., encapsulated) IPV6 seperti IPX, Appletalk, atau IPV6 itu sendiri.
Link :suatu fasilitas komunikasi atau medium di mana nodes dapat berkomunikasi di lapisanlink, yaitu., lapisan dengan seketika di bawah IPV6. Contoh adalah Ethernets ( sederhana atau bridged); PPP link; X.25, Frame Relay, atau jaringan ATM; dan lapisan internet ( atau lebih tinggi) " terowongan", seperti terowongan (di) atas IPV4 atau IPV6 itu sendiri.
Neighbors : nodes berkait dengan link yang sama.
Interface : suatu pemasangan nodes ke suatu link.
Address : suatu lapisan IPV6 identifier untuk interface atau satu set
Interface.
Paket : suatu header IPv6 ditambah payload.
Link MTU : unit transmisi yang maksimum, yaitu., ukuran paketmaksimum di dalam octets, yang dapat disampaikan satu potongan di atas suatu link.
Path MTU : link yang minimum MTU dari semua link di dalam suatu alur antara suatu sumber node dan suatu tujuan nodes.
.
2.3. IPV6 Header Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Prio. | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Versi 4-Bit Internet Protokol versi 6.
Prio. 4-Bit Nilai Prioritas.
Flow Label 24-bit flow label.
Payload length . 16-Bit unsigned integer. Panjangnya payload,yaitu., sisa dari paket yang mengikuti header IPV6 , di (dalam) octets. Jika nol, menunjukkan bahwa panjangnya payload dibawa adalah suatu payload Jumbo pilihan Hop-By-Hop .
Next Header 8-Bit Selektor. Identifikasi jenis header yang dengan seketika mengikuti header IPV6 .Gunakan nilai-nilai yang sama sebagai bidang protocol IPV4 [ RFC-1700 et seq.].
Hop limit 8-Bit unsigned integer. Dikurangi oleh 1 oleh masing-masing node yang ke depan paket itu. Paket dibuang jika hop limit dikurangi sampai nol.
Source address 128-Bit . Alamat mula-mula paket. Lihat [ RFC-1884].
Destination address 128-Bit. Alamat penerima yang diharapkan tentang paket ,mungkin bukan yang terakhir penerima, jika suatu routing header ada. Lihat [ RFC-1884] dan bagian 4.4.
2.4. Perluasan header IPV6
Di IPV6, opsional informasi internet-layer disandikan memisahkan Header yang mungkin ditempatkan antar header IPV6 dan yang bagian headerupper- layer di dalam suatu paket. Ada sejumlah kecil . seperti perluasan header, masing-masing yang dikenali oleh suatu Nilai header Berikutnya beda. Sebagai yang digambarkan contoh ini, suatu IPV6 paket boleh membawa nol, satu, atau lebih luas headernya, masing-masing yang dikenali oleh next header dari header yang terdahulu:
+---------------+------------------------
| IPv6 header | TCP header + data
| |
| Next Header = |
| TCP |
+---------------+------------------------
+---------------+----------------+------------------------
| IPv6 header | Routing header | TCP header + data
| | |
| Next Header = | Next Header = |
| Routing | TCP |
+---------------+----------------+------------------------
+---------------+----------------+-----------------+-----------------
| IPv6 header | Routing header | Fragment header | fragment of TCP
| | | | header + data
| Next Header = | Next Header = | Next Header = |
| Routing | Fragment | TCP |
+---------------+----------------+-----------------+-----------------
Dengan satu perkecualian, perluasan header tidaklah diuji atau diproses dengan nodes manapun sepanjang suatu alur penyerahan paket, sampai paket menjangkau
node( atau masing-masing satuan node, di dalam kasus multicast)
yang dikenali di dalam destination address header IPV6.
Demultiplexing normal pada next header IPV6 meminta modul untuk memproses perluasan header pertama,atau header upper-layer jika tidak ada perluasan header ditampilkan. Muatan Dan Ilmu semantik dari tiap perluasan header menentukan apakah atau bukan untuk memulai next header. Oleh karena itu, perluasan header harus diproses dengan ketat agar supaya mereka nampak di paket; sebuah penerima harus tidak, sebagai contoh, meneliti melalui suatu paket mencari sebuah jenis tertentu perluasan header dan memproses header prior itu sebelum pemrosesan terdahulu. Perkecualian menunjuk kepada paragraf yang terdahulu adalah Hop-By-Hop option header,dimana membawa informasi yang harus diuji dan diproses oleh tiap-tiap node sepanjang suatu alur penyerahan paket, termasuk
source dan destination nodes. Hop-By-Hop option header,
ketika ditampilkan, harus dengan seketika mengikuti header IPV6. Kehadiran nya
ditandai oleh nilai nol di [dalam] Bidang next header pada header IPV6.
Keberadaannya ditandai oleh nilai nol pada header field berkutnya dari Ipv6 header. Jika, sebagai hasil pengolahan header, suatu node diperlukan untuk berproses kepada header yang berikutnya tetapi header yang berikutnya menilai header yang sekarang adalah yang tak dikenali oleh node, header harus membuang paket dan mengirimkan suatu ICMP Pesan Masalah Parameter kepada sumber paket, dengan suatu ICMP Nilai Kode 2 (" Jenis header Berikutnya yang tak dikenali ") dan ICMP pointer field berisi offset nilai yang tak dikenali di dalam paket yang asli. Tindakan yang sama harus diambil jika Suatu node menghadapi suatu nilai header berikutnya nol dari semua header lain dibanding header pada IPV6.
Masing-Masing header perluasan adalah suatu bilangan bulat berbagai 8 komposisi 8 octet , di dalam memesan untuk mempertahankan 8-octet kelurusan header yang berikut. Multi-Bidang Komposisi 8 octet di dalam masing-masing header perluasan dibariskan pada batasan-batasan alami, yaitu., bidang lebar n komposisi music 8 suara ditempatkan pada suatubilangan bulat berbagai n komposisi music 8 suara dari start header, untuk n= 1,2, 4, atau 8.
Suatu implementasi IPV6 penuh meliputi implementasi mengikuti header perluasan :
Hop-by-Hop Options
Routing (Type 0)
Fragment
Destination Options
Authentication
Encapsulating Security Payload
2.4.1. Pesan Header Perluasan (Extension Header Order)
Ketika lebih dari header perluasan digunakan pada paket yang sama adalah dianjurkan header-header itu nampak pada pesan yang berikut:
IPv6 header
Hop-by-Hop Options header
Destination Options header (catatan 1)
Routing header
Fragment header
Authentication header (catatan 2)
Encapsulating Security Payload header (note 2)
Destination Options header (catatan 3)
upper-layer header
catatan 1: pilihan untuk diproses oleh tujuan yang pertama itu nampak IPV6 field Alamat Tujuan ditambah tujuan yang berikut yang ditampilkan pada Routing Header.
catatan 2: rekomendasi tambahan mengenai pesan yang berhubungan dengan Pengesahan dan Encapsulasi Security Payload Header disampaikan dalam [ RFC-1827].
Catatan 3 pilihan untuk diproses hanya tujuan akhir dari paket.
Masing-Masing perluasan header terjadi paling banyak sekali, kecuali header Pilihan Tujuan dapat terjadi paling banyak dua kali (sekali ketika sebelum Routing Header dan yang kedua sebelum header lapisan atas).
Jika header lapisan atas ( upper-layer header) adalah header IPV6 lain ( di dalam kasus IPV6 menjadi tunnel di atas encapsulasi IPV6), mungkin saja diikuti olehheader perluasan sendiri, yang secara terpisah tunduk kepada pesan yang sama.
Jika dan ketika header perluasan lain digambarkan, batasan pemesanan mereka sehubungan dengan header yang telah ditampilkan di atas harus ditetapkan.
IPV6 nodes harus menerima dan mencoba untuk memproses header air perluasan di manapun pesanan terjadi dalam paket yang sama, kecuali Hop-By-Hop header Pilihan yang mana terbatas untuknampak dengan seketika setelah suatu IPV6 header. Meskipun begitu, betul-betul dinasehatkan agar sumber paket IPV6 bertahan pada pesan yang direkomendasikan sampai kecuali jika spesifikasi yang berikut meninjau kembali rekomendasi tersebut.
2.4.2. Pilihan (options)
Dua di antara header perluasan yang didefinisikan sebagai Hop-By-Hop header Pilihan dan header pilihan Tujuan, membawa suatu variabel dengan tipe angka disebut sebagai type-length-value ( Type Length Value) yang disandikan " pilihan", dengan format berikut:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type 8-bit identifier of the type of option.
Opt Data Len 8-bit unsigned integer. Length of the Option
Data field of this option, in octets.
Option Data Variable-length field. Option-Type-specific
data.
Urutan pilihan di dalam suatu header harus diproses dengan keras di dalam pesan yang nampak pada header. Jenis Pilihan identifiers secara internal disandikan melalui highest-order 2 bits menetapkan tindakan yang harus diambil jika proses nodes IPV6 tidak mengenali Tipe pilihan:
00- melampaui;menghapuskan pilihan ini dan melanjut memproses header tersebut.
01- membuang paket [itu].
10- membuang paket, dengan mengabaikan ya atau tidaknya
Alamat Tujuan dari paket yaitu suatu multicast menunjuk, mengirimkan
suatu ICMP Parameter, Kode 2, pesan kepada milik paket
Alamat Sumber, menunjuk Pilihan yang tak dikenali tipe pilihan.
11- membuang paket [itu] dan, hanya jika Tujuan paket
Alamat bukanlah suatu multicast menunjuk, mengirimkan suatu ICMP Parameter
Masalah, Kode 2, pesan kepada Alamat Sumber paket,
menunjuk Jenis Pilihan yang tak dikenali.
Third-Highest-Order bit Jenis Pilihan menetapkan apakah data pilihan menyangkut pilihan itu dapat berubah en-route kepada tujuan paket akhir. Ketika suatu header Pengesahan hadir di paket, untuk pilihan data manapun siapapun boleh berubah,en-route keseluruhan field pilihan data harus diperlakukan sebagai komposisi 8 oktet nisli 0 ketika komputasi atau membuktikan keaslian paket itu.
0- Pilihan Data tidak berubah en-route
1- Pilihan Data boleh berubah en-route
Pilihan individu mungkin punya kebutuhan kelurusan spesifik, untuk memastikan bahwa multi-octet nilai-nilai di dalam Bidang Data Pilihan jatuh terpasang batasan-batasan alami. Kebutuhan Kelurusan dari suatu pilihan adalah yang ditetapkan menggunakan notasi xn+y, maksud/arti jenis pilihan harus nampak pada suatu bilangan bulat berbagai x komposisi 8 suara dari start header lebih y komposisi music 8 suara. Sebagai contoh:
2n berarti 2-octet manapun offset dari start header.
8n+2 [alat/ makna] 8-octet offset dari start header manapun lebih 2 dari
komposisi 8 suara.
Ada dua pilihan lapisan digunakan ketika diperlukan untuk membariskan pilihan yang berikut dan untuk memperpanjang itu berisi header dari suatu tentang 8 komposisi 8 octet. Pilihan Lapisan ini harus dikenali oleh semua implementasi IPV6.
Pad1 : Pilihan
+-+-+-+-+-+-+-+-+
| 0|
+-+-+-+-+-+-+-+-+
CATATAN! format Pad1 Pilihan adalah suatu kasus khusus dimana pengerjaannya bukan mempunyai panjang dan field nilai.
Pilihan pad1 digunakan untuk memasukkan/menyisipkan satu komposisi 8 octet ke dalamArea Pilihan suatu header. Jika komposisi 8 suara lebih dari satu lapisan maka diperlukan Pad n pilihan.
Pad n Pilihan ( Kebutuhan Kelurusan: tidak ada)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------
| 1| Memilih Data Len| Data Pilihan
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------
Pad n Pilihan digunakan untuk memasukkan/menyisipkan dua atau lebih komposisi music 8 suara lapisan ke dalam Area Pilihan header. Karena lapisan N komposisi 8 octet,Memilih field Data Len berisi nilai N-2, dan Pilihan data terdiri dari N-2 komposisi 8 octet nilai nol.
2.4.3 Hop-By-Hop header Pilihan
Hop-By-Hop header pilihan digunakan untuk membawa informasi opsional bahwa harus diuji oleh tiap-tiap nodes sepanjang suatu alur penyerahan paket. Hop-By-Hop header Pilihan dikenali oleh suatu Nilai header berikutnya Nol pada header IPV6, dan mempunyai format yang berikut:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header berikutnya | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .
| |
. .
. Options / pilihan .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header Berikutnya 8-Bit Selektor. Identifikasi header dengan seketika
mengikuti pilihan Hop-By-Hop header
Gunakan nilai-nilai yang sama sebagai field IPV4 Protokol [ RFC-1700 et seq.].
Hdr Ext Len 8-bit bilangan bulat tidak ditandai Panjangnya pilihan
Hop-By-Hop header di dalam 8-octet unit, belum
termasuk yang pertama 8 komposisi 8 octet.
Pilihan Variable-Length menyudahi Hop-By-Hop header
Pilihan adalah suatu bilangan bulat berbagai 8
komposisi 8 octet.
Sebagai tambahan terhadap Pad1 Dan Pad n Pilihan menetapkan bagian 4.2, hop-by-hop pilihan yang berikut digambarkan:
Jumbo Payload option ( Kebutuhan Kelurusan: 4N+ 2)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 194 | Memilih Data Len=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jumbo Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jumbo Payload digunakan untuk mengirimkan IPV6 paket dengan payload lebih panjang dibanding 65,535 komposisi 8 octet. Jumbo Payload Length adalah panjang paket di dalam komposisi 8 octet, tidak termasuk IPV6 header tetapi mencakup Hop-By-Hop header pilihan ; dimana harus lebih besar dari 65,535. Jika suatu paket diterima dengan suatu Jombo Payload, yang berisi suatu panjang dari Jumbo payload kurang dari atau sepadan dengan 65,535, suatu ICMP Pesan Parameter, Kode 0, harus dikirim kepada sumber paket, menunjuk ke high-order komposisi 8 octet yang cacat pada panjang field pada Jumbo Payload.
Field panjang Jumbo Payload di dalam IPV6 header harus mulai dari nol di dalam tiap-tiap paket yang membawa Pilihan Jumbo Payload tersebut. Jika sebuah paket diterima dengan suatu Jumbo Payload yang sah menyajikan dan suatu IPV6 tidak nol padap field Jumbo Payload, suatu ICMP Masalah Parameter.
Pesan Masalah Parameter, Kode 0, harus dikirim kepada milik paket sumber, menunjuk komposisi 8 octet yang pertama dari header Fragmen.
Suatu implementasi yang tidak mendukung Jumbo Payload tidak bisa mempunyai penghubung ke mata-mata rantai MTU dimana adalah lebih besar dari 65,575 ( 40 komposisi 8 octet IPV6 header yang lebih dari 65,535 komposisi 8 octet Payload).
2.4.4 Menaklukkan header (Routing Header)
Header Penaklukan digunakan oleh suatu sumber IPV6 untuk mendaftar satu atau lebih node intermediate yang“dikunjungi" di perjalanan ke suatu paket milik tujuan. Fungsinya adalah sangat serupa ke Rute Sumber pilihan IPV4'S. Header Penaklukan dikenali oleh suatu Nilai header berikutnya yaitu 43 pada header berikutnya dan mempunyai format yang berikut:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header berikutnya 8-Bit Selektor. Identifikasi jenis header
yang dengan seketika menaklukkan header
berikutnya
Gunakan nilai-nilai yang sama pada field IPV4 Protokol
[ RFC-1700 et seq.].
Hdr Ext Len 8-bit bilangan bulat Positif. Panjangnya Routing header dalam 8-octet unit, belum termasuk 8 octets pertama.
Routing Type 8-Bit identifier varian routing header tertentu.
Segmen Left 8-bit bilangan bulat tidak ditandatangani. Jumlah rute segmen yang tersisa, yaitu., jumlah daftar eksplisit node yang perlu dikunjungi sebelum mencapai tujuan yang akhir.
Type-Specific Data Variable-Length Bidang, tentang format yang ditentukan oleh Routing type, dan panjang dari suatu routing header yang lengkap adalah panjang suatu bilangan bulat kelipatan dari 8 octets
Jika, sedang memproses menerima sebuah paket, suatu node menemukan routing header dengan nilai yang tidak dikenali dari suatu routing type, perilaku yang diperlukan node tergantung pada nilai Segmeny Left field, seperti:
Jika Segmen Left adalah nol, node harus mengabaikan routing header dan mulai proses header yang berikutnya di paket, jenis siapa dikenali oleh header Yang berikutnya di dalam routing header.
Jika Segmen Left adalah tidak nol, node harus membuang paket itu dan mengirimkan suatu ICMP Parameter Problem, Kode 0, pesan kepada pemilik paket di alamat sumber, menunjuk routing type yang tidak dikenali.
Jika sebuah proses routing header dari paket penerima, semuah intermediate node menilai bahwa paket ini dikirimkan pada suatu link milih MTU yang lebih kecil dari ukuran paket, node harus menghilangkan paket dan mengirim sebuah ICMP Packet Too Big message kepada paket Alamat Sumber.
Jenis 0 Routing header mempunyai format yang berikut:
Next Header Hdr Ext Len Routing Type=0 Segments Lef
Reserved
Address[1]
Address[2]
Address[n]
Next header 8-Bit Selektor. Identifikasi jenis header
dengan seketika berikut routing header.
Menggunakan nilai-nilai yang sama sebagai IPV4 Protokol Field
[ RFC-1700 et seq.].
Hdr Ext Len 8-bit bilangan bulat positif. Panjangnya
Routing headerdi (dalam) 8-octet unit, belum termasuk 8 octets pertama. Karena Jenis 0 routing header, Hdr Ext Len harus sama dengan dua kali jumlah alamat di header.
Routing Type 0.
Segmen Left 8-bit bilangan bulat positif. Jumlah rute
segmen yang tersisa yaitu., jumlah explisit yang didaftarkan di intermediate nodes yang perlu dikunjungi sebelum mencapai tujuan yang akhir.
Reserved 32-bit reserved field. Memberikan nilai nol pada transmisi; mengabaikan saat menerima.
Address[1..N] vektor 128-bit menunjuk, nomor 1 untuk n.
Multicast Addresses harus tidak nampak dalam suatu routing header type 0, atau
di dalam IPV6 Bidang Alamat Tujuan suatu paket membawa suatu routing header type 0.
Sebuah routing header tidak diperiksa ato diproses sampai mencapai node yang di identifikasi di dalam Alamat Tujuan pada IPv6 header.
Cara Kerja ditunjukan pada algoritma di bawah ini :
if Segments Left = 0 {
proceed to process the next header in the packet, whose type is
identified by the Next Header field in the Routing header
}
else if Hdr Ext Len is odd or greater than 46 {
send an ICMP Parameter Problem, Code 0, message to the Source
Address, pointing to the Hdr Ext Len field, and discard the
packet
}
else {
compute n, the number of addresses in the Routing header, by
dividing Hdr Ext Len by 2
if Segments Left is greater than n {
send an ICMP Parameter Problem, Code 0, message to the Source
Address, pointing to the Segments Left field, and discard the
packet
}
else {
decrement Segments Left by 1;
compute i, the index of the next address to be visited in
the address vector, by subtracting Segments Left from n
if Address [i] or the IPv6 Destination Address is multicast {
discard the packet
}
else {
swap the IPv6 Destination Address and Address[i]
if bit i of the Strict/Loose Bit map has value 1 and the
new Destination Address is not the address of a neighbor
of this node {
send an ICMP Destination Unreachable -- Not a Neighbor
message to the Source Address and discard the packet
}
else if the IPv6 Hop Limit is less than or equal to 1 {
send an ICMP Time Exceeded -- Hop Limit Exceeded in
Transit message to the Source Address and discard the
packet
}
else {
decrement the Hop Limit by 1
resubmit the packet to the IPv6 module for transmission
to the new destination
}
}
}
}
Sebagai suatu contoh efek dari algoritma di atas, mempertimbangkan kasus suatu Sumber Node S mengirimkan suatu paket ke Tujuan Node D, menggunakan suatu routing header untuk menyebabkan paket itu untuk dikirimkan via intermediate Nodes pohon/bengkak urat] I1, I2, dan I3. Nilai-Nilai relevan IPV6 header dan routing header pada setiap segmen dari jalur pengiriman sebagai berikut:
As the packet travels from S to I1:
Source Address = S Hdr Ext Len = 6
Destination Address = I1 Segments Left = 3
Address[1] = I2
Address[2] = I3
Address[3] = D
As the packet travels from I1 to I2:
Source Address = S Hdr Ext Len = 6
Destination Address = I2 Segments Left = 2
Address[1] = I1
Address[2] = I3
Address[3] = D
As the packet travels from I2 to I3:
Source Address = S Hdr Ext Len = 6
Destination Address = I3 Segments Left = 1
Address[1] = I1
Address[2] = I2
Address[3] = D
As the packet travels from I3 to D:
Source Address = S Hdr Ext Len = 6
Destination Address = D Segments Left = 0
Address[1] = I1
Address[2] = I2
Address[3] = I3
2.4.5 Fragment Header
Fragment Header digunakan oleh suatu IPV6 sumber untuk mengirimkan paket lebih besar daripada memasukan pada jalur MTU menuju tujuannya. ( Catatan: tidak sama dengan IPV4, Fragmentasi di IPV6 dilakukan hanya oleh nodes sumber, bukan oleh routers sepanjang suatu alur pengiriman paket-- lihat bagian 5.) Fragment Header dikenali oleh suatu nilai header berikutnya deng nilai 44 di dalam pemrosesan header, dan mempunyai format yang berikut:
Next Header Reserved Fragment Offset Res M
Identification
Next Header 8-bit selector. Identifies the initial header type of the Fragmentable Part of the original packet (defined below). Uses the same values as the IPv4 Protocol field [RFC-1700 et seq.].
Reserved 8-bit reserved field. Initialized to zero for
transmission; ignored on reception.
Fragment Offset 13-bit unsigned integer. The offset, in 8-octet
units, of the data following this header,
relative to the start of the Fragmentable Part
of the original packet.
Res 2-bit reserved field. Initialized to zero for
transmission; ignored on reception.
M flag 1 = more fragments; 0 = last fragment.
Identification 32 bits. See description below.
Dalam pengiriman paket yang terlalu besar untuk diterima dalam MTU sebagai jalur tujuan, sebuah node sumber boleh membagi paket tersebut menjadi fragment-fragment dan mengirim setiap fragment sebagai paket terpisah, untuk dikembalikan lagi di receiver.
Setiap paket yang di fragmentasi, node sumber memunculkan sebuah nilai identifikasi. Nilai tersebut harus berbeda dengan fragmentasi paket yang sudah dikirim sama dengan Alamat sumber dan Alamat tujuan. Jika routing header menunjuk, Alamat tujuan akan menganggap ini adalah tujuan akhir.
* " baru-baru ini" berarti di dalam yang maksimum yang mungkin seumur hidup suatu paket,mencakup waktu pemindahan dari sumber ke tujuan dan waktu yang habis digunakan untuk menunggu reassembly dengan fragment lain dari paket yang sama. Bagaimanapun, itu tidaklah diperlukan bahwa suatu node sumber mengetahui yang maksimum umur hidup paket. Melainkan, itu mengira bahwa kebutuhan itu dapat dijumpai dengan pemeliharaan Nilai Identifikasi secara sederhana, 32- bit, " berputar balik" waktu masing-masing ditambahkan suatu paket harus terbagi-bagi. Itu adalah suatu pilihan implementasi apakah untuk memelihara counter tunggal untuk node atau berbagai counter, e.g., masing-masing dapat satu alamat sumber node mungkin, atau masing-masing dapat satu aktif kombinasi( alamat sumber, alamat tujuan).
Awal, paket tidak terbagi-bagi besar dikenal sebagai
" paket yang asli", dan itu dipertimbangkan untuk terdiri dari dua bagian,
seperti yang digambarkan:
paket asli:
Unfragmentable Part Fragmentable Part
Unfragmentable Part terdiri dari IPV6 header ditambah perluasan header yang harus diproses oleh node dan mengarahkan kepada tujuan, itu adalah, semua header yang ke atas dan termasuk routing header, selain itu Hop-By-Hop header pilihan, selain itu tidak ada perluasan header.
Fragmentable Part terdiri dari sisa dari paket, itu adalah, perluasan header yang kebutuhan diproses hanya oleh node tujuan akhir, ditambah upper layer header dan data.
Fragmentable Part dari paket yang asli adalah dibagi menjadi fragment-fragment, masing-masing, kecuali mungkin yang terakhir itu (" rightmost") satu, menjadi bilangan bulat kelipatan dari 8 octets. Fragment dipancarkan terpisah " fragment packets" seperti yang digambarkan:
paket asli:
Unfragmentable Part First Fragment Second Fragment ……… Last Fragment
fragment packets:
Unfragmentable Part Fragment Header First Fragment
Unfragmentable Part Fragment Header Second Fragment
o
o
o
Unfragmentable Part Fragment Header Last Fragment
Masing-Masing paket fragment adalah terdiri atas:
Unfragmentable Part dari paket yang asli, dengan Panjangnya Muatan IPV6 header yang asli berubah untuk berisi panjang paket fragment yang ini saja ( tidak termasuk panjang IPV6 header sendiri), dan bidang header yang berikutnya dari header terakhir dari unfragmentable part yang diubah ke 44.
Isi Fragment Header :
Nilai HeaderYang berikutnya yang mengidentifikasi header yang pertama dari fragmentable part dari paket yang asli.
Suatu Offset Fragmen yang berisi offset fragment, di dalam 8-octet unit, sehubungan dengan start fragmentable part dari paket yang asli. Fragmen Offset yang pertama ("leftmost") fragment adalah 0.
Nilai flag M adalah 0 jika fragment adalah yang terakhir ("rightmost") satu, selain itu nilai flag M adalah 1.
Nilai Identifikasi dihasilkan untuk paket yang asli.
Fragment itu sendiri
Panjangnya fragmen harus dipilih seperti yang menghasilkan
paket fragmen yang cocok di dalam MTU dari alur kepada paket-paket tujuan.
Di tujuan, fragment paket dikumpulkan kembali ke dalam format yang asli, seperti yang digambarkan:
Paket asli yang dikumpulkan kembali:
Unfragmentable Part Fragmentable Part
Aturan yang berikut mengurus reassembly:
Suatu paket asli dikumpulkan kembali hanya dari paket fragmen yang
mempunyai Alamat Sumber yang sama, Alamat Tujuan, dan Fragmen
Identifikasi.
Bagian header berikutnya yang merupakan bagian terakhir yang tidak bisa dibagi-bagi diperoleh dari bagian header yang berikutnya lebih dulu sebagai bagian awal dari header fragmen. Payload Length yang dikumpulkan kembali dihitung dari panjang bagian yang tidak bisa dibagi-bagi lagi. Sebagai contoh, suatu rumusan untuk menghitung Payload Length paket asli yang dikumpulkan kembali adalah:
PL.ORIG= PL.FIRST- FL.FIRST- 8+ ( 8* FO.LAST)+ FL.LAST
[di mana/jika]
PL.ORIG= Bidang Payload Length paket dikumpulkan kembali.
PL.FIRST= Bidang Payload Length paket fragmen pertama.
FL.FIRST= panjangnya fragmen yang mengikuti bagian header Fragmen
paket fragmen pertama.
FO.LAST= Bidang Offset Fragmen header Fragmen yang bertahan/berlangsung paket fragmen.
FL.LAST= panjangnya fragmen yang mengikuti header Fragmen paket fragmen.
Yang bisa membagi-bagi Bagian dari paket yang dikumpulkan kembali dibangun
dari fragmen yang mengikuti header Fragmen itu pada setiap paket fragmen.
Panjang fragmen masing-masing dihitung oleh pengurangan dari Payload Length paket panjang header antara header IPV6 dan fragmennya sendiri.HeaderFragmen tidak terdapat di bagian akhir, paket.dikumpulkan kembali.
Kesalahan yang berikut Kondisi-Kondisi boleh [muncul/bangkit] ketika pengumpulan kembali paket terbagi-bagi. Jika fragmen tidak cukup diterima untuk melengkapi reassembly paket di dalam 60 detik yang pertama kali datang dari paket tersebut dilakukan reassembly semua fragmen yang telah diterima untuk paket harus dibuang. Jika fragmen yang pertama (dengan suatu Offset Fragmen nol) telah diterima, suatu ICMP Time Exceeded fragmen melakukan Reassembly Time Exceed yang memberikan pesan seharusnya dikirim ke sumber fragmen itu .
Jika panjang suatu fragmen diperoleh dari fragmen milik paket Bidang Payload Length, bukanlah 8 komposisi music 8 suara dan M Flag fragmen itu adalah 1, kemudian fragmen itu harus dibuang dan suatu ICMP Masalah Parameter, Kode 0, pesan harus dikirim kepada sumber fragmen, menunjuk Payload length field dari paket fragmen.
Jika panjangnya dan offset suatu fragmen sedemikian hingga Payload length field paket mengumpulkan kembali dari yang fragmen akan melebihi 65,535 komposisi music 8 suara, kemudian fragmen itu harus dibuang dan suatu ICMP Masalah Parameter, Kode 0, pesan harus dikirim kepada sumber fragmen, menunjuk Bidang Offset paket fragme itu.
Kondisi-Kondisi yang berikut tidaklah diharapkan untuk terjadi, tetapi bukanlah kesalahan yang dipertimbangkan jika mereka lakukan Nomor; Jumlah Dan Isi header yang terdahulu Fragmen Header dari fragmen paket yang asli sama yang berbeda boleh berbeda. Apapun juga header berada sebelum fragmen.
Header pada setiap paket fragmen, diproses ketika paket tiba, sebelum antri fragmen itu untuk reassembly. Header itu di dalam Offset nol paket fragmen ditahan paket yang dikumpulkan kembali itu.
Header yang berikutnya menilai header dari fragmen yang berbeda dengan fragmen paket asli yang sama boleh berbeda. Hanya nilai dari Offset nol paket fragmen digunakan untuk reassembly.
2.4.6 Destinations optional Header
Optional header digunakan untuk membawa informasi opsional kebutuhan yang diuji hanya oleh suatu tujuan paket nodes.
Optional header dikenali oleh suatu Nilai header berikutnya 60 di (dalam) header yang dengan seketika terdahulu, dan mempunyai format yang berikut:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header berikutnya 8-Bit Selektor. Identifikasi jenis header yang mengikuti optional header. Gunakan nilai-nilai yang sama [sebagai/ketika] IPV4 Bidang Protokol [ RFC-1700 et seq.].
Hdr Ext Len 8-bit bilangan bulat tidak ditandai. Panjangnya PEmi di (dalam) 8-octet unit, belum termasuk yang pertama 8 komposisi music 8 suara.Pilihan Variable-Length Bidang, tentang panjangnya . seperti (itu) [bahwa/yang] melengkapi;menyudahi Serudukan/Palu air Pilihan Tujuan adalah suatu bilangan bulat berbagai 8 komposisi music 8 suara [panjang/lama]. Isi satu atau lebih Pilihan TLV-encoded, [seperti/ketika] diuraikan di (dalam) bagian 4.2.Satu-Satunya pilihan tujuan menggambarkan dokumen ini adalah Pad1dan Padn Pilihan menetapkan bagian 4.2.
Catat bahwa ada dua jalan mungkin untuk menandai tujuan pemilihan informasi di suatu paket IPV6: baik sebagai suatu pilihan di destination optional header , atau sebagai suatu header perluasan terpisah. Header fragmen dan Header Pengesahan adalah contoh yang paling mendekati. Pendekatan yang mana dapat digunakan tergantung pada tindakan apa yang diinginkan untuk suatu [tujuan yang tidak memahami pemilihan informasi.
o jika yang diinginkan adalah tindakan untuk tujuan membuang paket dan, jika hanya Alamat Tujuan paket bukanlah suatu multicast menunjuk, mengirimkan suatu ICMP Tak mengenali Pesan Jenis untuk Alamat Sumber paket, kemudian informasi mungkin yang disandikan baik sebagai suatu header terpisah atau sebagai suatu pilihan .
Pemilihan optional header jenis apa mempunyai nilai 11 dalam highest-order dua puluh lima sen. Pilihan boleh tergantung pada faktor yang mengambil lebih sedikit komposisi music 8 suara, atau hasil yang lebih baik, penguraian lebih efisien.
o bila ada lain tindakan diinginkan, informasi harus disandikan sebagai suatu pilihan di dalam header tujuan mempunyai nilai 00, 01, atau 10 dalam nya highest-order dua puluh lima sen, penetapan tindakan yang diinginkan ( lihat bagian 4.2).
2.4.7 Tidak (ada) Header berikutnya
Nilai 59 Bidang header yang berikutnya dari suatu IPV6 atau manapun header perluasan menunjukkan bahwa tidak ada apapun berikut yang header. Jika Payload length field header IPV6 menandai (adanya) kehadiran komposisi music 8 suara yang lampau ujung suatu header Berikutnya yang berisi 59, komposisi music 8 suara itu harus diabaikan, dan diteruskan tanpa perubahan jika paket disampaikan.
2.5. Masalah Ukuran Paket
IPV6 memerlukan bahwa tiap-tiap mata rantai di (dalam) internet mempunyai suatu MTU 576 komposisi music 8 suara atau lebih besar. Pada mata rantai manapun yang tidak bisa menyampaikan 576-octet paket di dalam satu potongan, pemecahan menjadi kepingan link-specific dan reassembly harus yang disajikan pada suatu lapisan di bawah IPV6.
Hubungkan bahwa mempunyai suatu MTU configurable ( sebagai contoh, PPP mata rantai [ RFC-1661]) harus yang diatur untuk mempunyai suatu MTU sedikitnya 576 komposisi music 8 suara itu direkomendasikan bahwa suatu MTU lebih besar diatur, untuk mengakomodasi mungkin encapsulations ( yaitu. pembangunan penghubung) tanpa mengakibatkan pemecahan menjadi kepingan. betul-betul direkomendasikan IPV6 Alur pesawat itu MTU Penemuan [ RFC-1191], dalam rangka menemukan dan mengambil keuntungan dari alur dengan MTU lebih besar dari 576 komposisi music 8 suara. Bagaimanapun, suatu IPV6 minimal implementasi ( e.g., di (dalam) suatu sepatu boot ROM) [yang] bisa dipastikan membatasi [dirinya] sendiri untuk mengirimkan paket tidak (ada) lebih besar dari 576 komposisi music 8 suara, dan menghilangkan implementasi Alur MTU Penemuan.
Untuk mengirimkan suatu paket lebih besar dari suatu alur MTU, node boleh menggunakan IPV6 Header Fragmen untuk membagi-bagi paket itu di sumber dan mengumpulkan kembali di tempat tujuan. Bagaimanapun, pemecahan menjadi kepingan manapun aplikasi yang bias melakukan penyesuaian paket nya untuk cocok alur yang terukur MTU ( yaitu., hingga [menuju] ke 576 komposisi music 8 suara). Suatu node harus mampu menerima suatu paket yang terbagi-bagi, setelah reassembly, adalah sama besar seperti 1500 komposisi music 8 suara, mencakup header IPV6 itu. Suatu node dapat menerima paket yang terbagi-bagi untuk mengumpulkan kembali lebih dari 1500 komposisi music 8 suara.
Bagaimanapun, suatu node tidak harus mengirimkan fragmen yang mengumpulkan kembali suatu ukuran lebih besar dari 1500 komposisi music 8 suara kecuali jika mempunyai pengetahuan tegas/eksplisit bahwa destination dapat mengumpulkan kembali ukuran paket itu.
Sebagai jawaban atas suatu IPV6 paket yang dikirim untuk suatu IPV4 ( yaitu., suatu paket yang mengalami terjemahan dari IPV6 ke IPV4), memulai node IPV6 boleh menerima suatu Paket besar pesan ICMP pelaporan suatu NEXT-HOP MTU kurang dari 576.Node IPV6 bukan diperlukan untuk mengurangi ukuran paket untuk kurang dari 576, tetapi harus meliputi suatu header Fragmen dalam paket itu sedemikian sehingga IPV6-TO-IPV4 penerjemahan dapat memperoleh suatu Identifikasi untuk menggunakan menghasilkan IPV4 fragmen. Catat bahwa ini berarti Payload field mungkin telah untuk mengurangi 528 komposisi music 8 suara ( 576 kurang 40) untuk header IPV6 dan 8 untuk header Fragmen), dan lebih kecil masihkah jika perluasan header tambahan digunakan.
2.6. Flow Label
24-Bit Bidang arus Label di dalam header IPV6 digunakan oleh sumber ke label paket itu di mana hal itu membutuhkan penanganan khusus dengan IPV6 penerus, seperti mutu [jasa;layanan]. Aspek/Pengarah IPV6 ini adalah, ketika menulis,namun bersifat percobaan dan tunduk kepada perubahan sesuai kebutuhan untuk arus mendukung Internet menjadi lebih jelas. Penghuni Atau Penerus yang tidak mendukung fungsi Arus Bidang Label diperlukan untuk menetapkan bidang itu nol ketika permulaan suatu paket, menyampaikan bidang tanpa perubahan ketika penyampaian suatu paket, dan mengabaikan bidang ketika menerima suatu paket.
Suatu arus adalah suatu urutan paket mengirim dari sumber tertentu untuk sesuatu tertentu ( unicast atau multicast) di mana tujuan sumber menginginkan penanganan khusus oleh penerus. Sifat alami disampaikan kepada penerus oleh suatu kendali protokol, seperti suatu protokol reservasi sumber daya, atau informasi di dalam arus paket mereka, e.g., di (dalam) suatu hop-by-hop pilihan.Detil . seperti (itu) protokol kendali atau pilihan adalah di luar lingkup tentang dokumen ini. Mungkin ada berbagai arus aktif dari suatu sumber ke tujuan, baik seperti lalu lintas yang tidak dihubungkan dengan arus manapun.
Suatu arus dengan uniknya dikenali oleh kombinasi suatu sumber menunjuk label arus tidak nol. Paket yang bukan kepunyaan suatu arus membawa label nol.
Suatu label arus ditugaskan untuk suatu arus oleh node sumber arus. Label baruarus harus terpilih ( pseudo-randomly) dan yang seragam mencakup dari 1 ke FFFFFF. Tujuan alokasi yang acak untuk membuat satuan bit manapun di dalam Bidang Label Arus yang pantas untuk penggunaan suatu dengan penerus.
Semua paket yang kepunyaan arus yang sama harus dikirim dengan alamat sumber yang sama, alamat tujuan, prioritas, dan label arus. Jika manapun paket itu meliputi semua Hop-By-Hop optional header, kemudian mereka semua harus dimulai dengan Hop-By-Hop optional header yang sama. Bila ada paket itu semua meliputi suatu header, kemudian mereka semua harus dimulai dengan muatan/indeks yang sama dalam semua perluasan
Header yang atas ke dan termasuk routing header. Jika suatu pelanggaran dideteksi, haruslah dilaporkan kepada sumber oleh suatu ICMP Pesan Masalah Parameter, Kode 0, menunjukkan high-order komposisi music 8 suara Bidang Arus Label ( yaitu., offset 1 di dalam IPV6 paket).
Penerus bebas untuk " opportunistically" yang disediakan flow-handling status untuk arus manapun, bahkan ketika tidak ada informasi penetapan arus telah disajikan via suatu protokol kendali, suatu hop-by-hop pilihan, atau lain [alat/ makna]. Sebagai contoh, [atas/ketika] menerima suatu paket dari sumber tertentu dengan suatu label arus tidak nol yang tak dikenal, suatu penerus boleh memproses header IPV6 nya dan perluasan header manapun perlu seolah-olah label arus adalah nol. Bahwa pengolahan akan menentukan next-hop alat penghubung, dan mungkin tindakan lain, seperti pembaharuan hop-by-hop pilihan, mempercepat tongkat penunjuk dan menunjuk suatu Routing header, atau memutuskan bagaimana cara antri paket berdasar pada Prioritas nya Bidang. Penerus boleh kemudian memilih untuk " ingat" hasil itu semua memproses langkah-langkah dan tempat yang menyembunyikan informasi, menggunakan alamat sumber sebagai kunci tempat menyembunyikan. Paket yang berikut dengan sumber yang sama menunjuk dan arus label boleh kemudian ditangani dengan menunjuk kepada informasi yang cache.
Flow-handling menyatakan bahwa disediakan dengan tegas, untuk contoh oleh suatu protokol kendali atau suatu hop-by-hop pilihan, harus ditetapkan sebagai bagian dari spesifikasi yang tegas/eksplisit membangun mekanisme; mungkin melebihi 6 detik.
Ketika suatu node stop dan start kembali itu harus saksama bukan untuk menggunakan suatu label arus bahwa itu mungkin telah menggunakan untuk suatu arus. Ini mungkin yang terpenuhi dengan perekaman pemakaian label arus stabil sedemikian sehingga dapat diingat label arus sampai maksimum tentang segala mungkin sebelumnya arus yang dibentuk telah berakhir ( sedikitnya 6 detik arus membangun mekanisme dengan umur hidup lebih panjang mungkin telah digunakan). Jika waktu yang minimum untuk node kembali, waktu itu dapat dikurangi dari penantian yang perlu permulaan untuk mengalokasikan label arus.
Tidak ada kebutuhan bahwa semua, atau bahkan kebanyakan, paket mengalir, yaitu membawa label arus tidak nol. Pengamatan ini ditempatkan di sini untuk mengingatkan para perancang protokol dan pelaksana untuk mengasumsikan cara lainnya. Sebagai contoh,adalah bodoh untuk mendisain suatu penerus yang bersifat cukup hanya jika kebanyakan paket kepunyaan arus, atau untuk mendisain suatu rencana tekanan header yang hanya bekerja/lancar pada [atas] paket itu.
2.7. Prioritas
4-Bit Bidang Prioritas di (dalam) IPV6 header memungkinkan suatu sumber untuk mengidentifikasi prioritas penyerahan yang diinginkan tentang paket nya , sehubungan dengan lain paket dari sumber yang sama [itu]. Nilai-Nilai Prioritas dibagi ke dalam dua cakupan: Nilai 0 melalui/sampai 7 digunakan untuk menetapkan prioritas tentang lalu lintas di mana sumber menyediakan kendali buntu, yaitu., lalu lintas yang " mengundurkan diri" sebagai jawaban atas buntu, seperti TCP lalu lintas. Nilai 8 melalui/sampai 15 digunakan untuk menetapkan prioritas lalu lintas yang tidak mengundurkan diri sebagai jawaban atas buntu, e.g.," real-time" paket dikirim pada suatu tingkat tarip tetap. Karena lalu lintas congestion-controlled, Nilai-Nilai Prioritas yang berikut adalah yang direkomendasikan untuk kategori aplikasi tertentu:
0- lalu lintas tidak ditandai
1- " pengisi" lalu lintas ( e.g., netnews)
2- perpindahan data tanpa kendali ( e.g., email)
3- ( yang dipesan)
4- perpindahan curah yang menghadiri ( e.g., FTP, NFS)
5- ( yang dipesan)
6- lalu lintas interaktip ( e.g., telnet, X)
7- internet mengendalikan lalu lintas ( e.g., menaklukkan protokol, SNMP)
Jika waktu minimum yang diperlukan untuk mereboot cabangnya diketahui(seringkali lebih dari 6 detik). Waktu tsb dapat dikurangi dari periode penantian yang diperlukan sebelum memulai untuk mengalokasi arus label. Tidak ada persyaratan bahwa semua bahkan kebanyakan paket kepunyaan dari aliran, i.e., carry non-zero flow labels. Pengamatan ini ditempatkan disini untuk mengingatkan para perancang protokol dan pelaksana untuk tidak mengasumsikan cara lainnya. Sebagai contoh, akan bersifat tidak bijak untuk mendisain suatu penerus siapa yang penampilannya akan bersifat cukup hanya jika kebanyakan paket merupakan kepunyaan arus, atau untuk mendisain suatu rencana tekanan yang hanya bekerja/lancar pada paket kepunyaan arus.
Karena lalu lintas non-congestion-controlled, Prioritas yang paling rendah menghargai ( 8) harus digunakan untuk yang paket pengirim adalah paling berkeinginan sudah membuang di bawah kondisi-kondisi buntu ( e.g., kesetiaan tinggi lalu lintas video), dan nilai yang paling tinggi ( 15) harus digunakan untuk yang paket pengirim adalah paling sedikit berkeinginan sudah membuang ( e.g., low-fidelas lalu lintas audio). Tidak ada hubungan pemesanan tersiratkan antara prioritas yang congestion-controlled dan yang tidak buntu- prioritas yang dikendalikan.
2.8. Persoalan Upper-Layer Protocol
2.8.1 Upper-Layer Checksums(Lapisan atas Checksums)
Suatu pengangkutan atau lain protokol lapisan atas yang meliputi address dari header IP dalam checksum perhitungan nya harus dimodifikasi untuk menggunakan diatas IPV6, untuk meliputi alamat 128-BIT IPV6
sebagai ganti 32-BIT IPV4 menunjuk. Khususnya, yang berikut ini ilustrasi menunjukkan TCP dan UDP " pseudo-header" untuk IPV6:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Alamat Sumber +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Alamat Tujuan +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Panjangnya Muatan penghasil untung |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nol | Header Berikutnya |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Header Yang berikutnya menghargai pseudo-header mengidentifikasi protokol lapisan atas ( e.g., 6 untuk TCP, atau 17 untuk UDP). Itu akan berbeda dengan Header Yang berikutnya menghargai IPV6 header jika di sana adalah header perluasan antara IPV6 header dan yang bagian atas- header lapisan.
o Panjangnya Muatan penghasil untung menggunakan pseudo-header adalah panjang paket lapisan atas, mencakup header lapisan atas . Itu akan jadi kurang dari Panjangnya Muatan penghasil untung di dalam IPV6 header ( atau di dalam Jumbo Pilihan Muatan penghasil untung) jika ada header perluasan antara IPV6 header dan header lapisan atas.
o Tidak sama dengan IPV4, kapan UDP paket dimulai oleh suatu IPV6, UDP checksum tidaklah opsional. Itu adalah, kapan saja permulaan suatu UDP paket, suatu IPV6 harus menghitung suatu UDP checksum diatas paket dan pseudo-header, dan, jika itu perhitungan menghasilkan suatu hasil nol, [itu] harus diubah ke heksa FFFF untuk penempatan didalam UDP header . IPV6 penerima harus barang buangan UDP paket yang berisi suatu nol checksum, dan perlu membukukan kesalahan.
IPV6 versi ICMP [ RFC-1885] meliputi di atas pseudo-header dalam checksum perhitungan nya ; ini adalah suatu perubahan dari IPV4 versi tentang ICMP, yang tidak meliputi suatu pseudo-header dalam checksum nya . Alasan untuk perubahan adalah untuk melindungi ICMP dari misdelivery atau korupsi bidang IPV6 header yang di atasnya itu semua tergantung, yang mana, tidak sama dengan IPV4, tidaklah dicakup oleh suatu internet-layer checksum. Bidang Header Yang berikutnya didalam pseudo-header untuk ICMP berisi menghargai 58, yang mengidentifikasi IPV6 versi ICMP [itu].
2.8.2 Maximum Packet Lifetime
Tidak sama dengan IPV4, IPV6 node tidaklah diperlukan untuk menyelenggarakan paket maksimum seumur hidup. Itu adalah alasan IPV4 " Waktu untuk Tinggal" bidang adalah yang dinamai kembali " Batas Loncatan" didalam IPV6. Dalam praktek, seluruh sedikit, bila ada, IPV4 implementasi menyesuaikan diri kepada kebutuhan yang mereka membatasi paket seumur hidup, maka ini adalah tak satu perubahan pun dalam praktek. Manapun lapisan atas protokol yang bersandar pada internet layer itu ( apakah IPV4 atau IPV6) untuk membatasi paket seumur hidup hendaknya diupgrade untuk menyediakan sendiri mekanisme untuk mendeteksi dan membuang paket usang.
2.8.3 Maximum Upper-Layer Payload Size
Ketika menghitung ukuran muatan penghasil untung yang maksimum yang tersedia untuk lapisan atas data, suatu lapisan atas protokol harus mempertimbangkan ukuran yang lebih besar tentang IPV6 header sehubungan dengan IPV4 header itu. Sebagai contoh, didalam IPV4, TCP'S MSS pilihan dihitung seperti ukuran paket yang maksimum ( sebuah nilai anggapan atau suatu nilai mempelajari sampai Alur MTU Penemuan) kurang 40 komposisi music 8 suara ( 20 komposisi music 8 suara untuk MINIMUM-LENGTH IPV4 header dan 20 komposisi music 8 suara untuk MINIMUM-LENGTH TCP header ).
Ketika menggunakan TCP diatas IPV6, MSS harus dihitung seperti ukuran paket yang maksimum kurang 60 komposisi music 8 suara, sebab MINIMUM-LENGTH IPV6 header ( yaitu., suatu IPV6 header dengan tidak ada header perluasan) adalah 20 komposisi music 8 suara lebih panjang dibanding suatu minimum-length IPV4 header .
Internet Versi Protokol 6 disingkat ke IPV6. Versi yang sebelumnya Internet Protokol adalah versi 4 ( dikenal sebagai IPV4).
IPV6 adalah suatu versi IP baru yang mana dirancang untuk;menjadi suatu langkah evolusiner dari IPV4. Ini merupakan suatu kenaikan alami ke IPV4. Ini dapat diinstall sebagai perangkat lunak yang dapat diupgrade normal di peralatan internet dan interoperable dengan IPV4 yang sekarang . Strategi Penyebaran nya dirancang untuk tidak mempunyai flagdays atau ketergantungan lainnya. IPV6 dirancang untuk menjalankan dengan baik pada jaringan capaian tinggi ( e.g. Gigabit Ethernet, OC-12, ATM, dll.) dan pada waktu yang sama tetap efisien untuk jaringan bandwitch rendah ( e.g. tanpa kawat). Sebagai tambahan, itu menyediakan suatu platform untuk internet kemampuan baru yang akan diperlukan di masa dekat mendatang.
IPV6 meliputi suatu mekanisme transisi yang mana dirancang untuk mengijinkan para pemakai untuk mengadopsi dan menyebar IPV6 di dalam menghamburkan pertunjukan yang tinggi dan untuk menyediakan interoperabilas langsung antara IPV4 dan IPV6 hosts. Transisi suatu versi baru Internet Protokol harus incremental, dengan sedikit atau tidak ada kritis interdependencies, jika itu adalah untuk berhasil. IPV6 transisi mengijinkan para pemakai [itu] untuk mengupgrade hosts mereka ke IPV6, dan operator jaringan untuk menyebar IPV6 di penerus, dengan sangat kecil koordinasi antara keduanya.
IPV6 Kelompok Kerja
IPV6 kelompok kerja adalah suatu IETF kelompok kerja mencarter untuk mengembangkan generasi yang berikutnya Internet Protokol. Kelompok kerja sebelumnya dinamai IP Next Generation Working Group (IPNGWG).
IPV6 kelompok kerja menghadirkan puncak dari banyak kelompok kerja di dalam IETF yang bekerja pada masalah routing dan masalah pengalamatan.
6Bone adalah IPV6 tulang punggung yang telah disediakan untuk membantu evolusi dan penyebaran IPV6 di Internet . 6Bone memulai sebagai konsep di tahun 1995 dan telah dibuat fondasi oleh suatu pertemuan pada Maret 1996 IETF yang bertemu Los Angeles. Sekarang ada site 6Bone di negara-negara di Asia, Australia Austria, Eropa, dan Amerika Utara. Semua 6Bone lokasi ditunjukkan pada 6Bone peta topologi. Kelompok kerja Transisi Generasi Yang berikutnya di IETF adalah bertanggung jawab untuk merancang mekanisme dan memeriksa prosedur untuk mendukung transisi Internet dari IPV4 ke IPV6.
6Ren adalah suatu prakarsa koordinasi Jaringan Pendidikan Dan Riset sukarela/fakultatif yang menyediakan produksi pemindahan IPV6 melayani untuk memudahkan mutu tinggi, performance yang tinggi, dan jaringan IPV6 secara operasional sempurna. Keikutsertaan bebas dan terbuka bagi semua Riset Dan Jaringan Pendidikan yang menyediakan IPV6 servis. Lain untuk keuntungan dan tidak untuk keuntungan IPV6 juga didukung untuk mengambil bagian.
Suatu gabungan yang meliputi seluruh dunia memimpin Penjual Internet, Riset& Jaringan Pendidikan sedang membentuk Forum IPV6 , dengan suatu misi jelas untuk mempromosikan IPV6 dengan secara dramatis meningkatkan kesadaran pemakai dan pasar IPV6 .
2.1.2 Pengembangan IPV6
- Perubahan dari IPV4 ke IPV6 terutama pada:
o Memperluas Kemampuan Pengalamatan
IPV6 meningkatkan alamat IP dari 32 bit - 128 bit, untuk
mendukung lebih banyak tingkatan dari pengalamatan hirarki, suatu jumlah yang lebih besar untuk pengalamatan nodes, dan auto-configuration yang lebih sederhana dari pengalamatan. Scalabilas multicast routing ditingkatkan dengan menambahkan sebuah " lingkup" bidang ke alamat multicast .Dan suatu jenis baru dari alamat disebut suatu " alamat anycast " digambarkan, digunakan untuk mengirimkansuatu paket kepada beberapa orang suatu kelompok .
o Penyederhanaan Format Header
Beberapa bidang header IPV4 telah dijatuhkan atau dibuat opsional, untuk mengurangi ongkos pemrosesan common case dari packet handling dan untuk membatasi ongkos bandwitch dari header IPV6.
o Meningkatkan support untuk perluasan dan pilihan
Merubah cara pilihan header IP disandikan mempertimbangkan penyampaian yang lebih efisien, lebih sedikit keras membatasi pada panjangnya pilihan, dan fleksibilitas lebih besar untuk memperkenalkan pilihan baru di masa datang.
o Mengalirkan Kemampuan Labeling
Suatu kemampuan baru ditambahkan untuk dapat melabelkan paket kepunyaan lalu lintas tertentu " arus" di mana pengirim meminta penanganan khusus, seperti kualitas yang tidak pasti dari servis atau ‘ real time’ service
o Pengesahan Dan Kemampuan Privasi.
Perluasan untuk mendukung pengesahan, integritas data, dan ( opsional) kerahasiaan data ditetapkan untuk IPV6.
2.1.3 Spesifikasi IPV6
Suatu daftar dari spesifikasi IPV6 secara umum diorganisasikan oleh fungsi. Daftar dari spesifikasi IPV6 oleh IETF Standardization Status
2.1.4 Implementasi IPV6
Implementasi IPV6 dikembangkan untuk banyak penerus dan sistem operasi host berbeda. Banyak yang sekarang mengirimkan produk. Ini meliputi implementasi host : Apple, BSDI, Bull, Digital, Epilogue, FreeBSD, FTP Software, Hitachi, HP, IBM, INRIA, Interpeak, Linux, Mentat, Microsoft, NetBSD, Nokia, Novell, NRL, NTHU, OpenBSD, Pacific Softworks, Process Software, SICS, SCO, Siemens Nixdorf, Silicon Graphics, Sun, UNH, and WIDE, and router implementations by 3Com, 6WIND, Bay Networks, cisco Systems, Digital, Hitachi, IBM, Merit (routing protocols), Nokia, NTHU, Sumitomo Electric, and Telebit Communications.
2.2 Istilah
Node : suatu alat yang mengimplementasikanIPV6.
Routes :suatu node yang ke depan paket IPV6 tidak dengan tegas yang menunjukkan dirinya sendiri.
Host : beberapa nodes yang bukan router.
Upper layer : suatu lapisan protokol yang dengan seketika di atas IPV6. Contoh :
protokol pengangkutan seperti TCP dan UDP, kendali protocol seperti ICMP, routing protokol seperti OSPF, dan internet atau lower-layer protokol menjadi " tunneled" atas ( yaitu., encapsulated) IPV6 seperti IPX, Appletalk, atau IPV6 itu sendiri.
Link :suatu fasilitas komunikasi atau medium di mana nodes dapat berkomunikasi di lapisanlink, yaitu., lapisan dengan seketika di bawah IPV6. Contoh adalah Ethernets ( sederhana atau bridged); PPP link; X.25, Frame Relay, atau jaringan ATM; dan lapisan internet ( atau lebih tinggi) " terowongan", seperti terowongan (di) atas IPV4 atau IPV6 itu sendiri.
Neighbors : nodes berkait dengan link yang sama.
Interface : suatu pemasangan nodes ke suatu link.
Address : suatu lapisan IPV6 identifier untuk interface atau satu set
Interface.
Paket : suatu header IPv6 ditambah payload.
Link MTU : unit transmisi yang maksimum, yaitu., ukuran paketmaksimum di dalam octets, yang dapat disampaikan satu potongan di atas suatu link.
Path MTU : link yang minimum MTU dari semua link di dalam suatu alur antara suatu sumber node dan suatu tujuan nodes.
.
2.3. IPV6 Header Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Prio. | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Versi 4-Bit Internet Protokol versi 6.
Prio. 4-Bit Nilai Prioritas.
Flow Label 24-bit flow label.
Payload length . 16-Bit unsigned integer. Panjangnya payload,yaitu., sisa dari paket yang mengikuti header IPV6 , di (dalam) octets. Jika nol, menunjukkan bahwa panjangnya payload dibawa adalah suatu payload Jumbo pilihan Hop-By-Hop .
Next Header 8-Bit Selektor. Identifikasi jenis header yang dengan seketika mengikuti header IPV6 .Gunakan nilai-nilai yang sama sebagai bidang protocol IPV4 [ RFC-1700 et seq.].
Hop limit 8-Bit unsigned integer. Dikurangi oleh 1 oleh masing-masing node yang ke depan paket itu. Paket dibuang jika hop limit dikurangi sampai nol.
Source address 128-Bit . Alamat mula-mula paket. Lihat [ RFC-1884].
Destination address 128-Bit. Alamat penerima yang diharapkan tentang paket ,mungkin bukan yang terakhir penerima, jika suatu routing header ada. Lihat [ RFC-1884] dan bagian 4.4.
2.4. Perluasan header IPV6
Di IPV6, opsional informasi internet-layer disandikan memisahkan Header yang mungkin ditempatkan antar header IPV6 dan yang bagian headerupper- layer di dalam suatu paket. Ada sejumlah kecil . seperti perluasan header, masing-masing yang dikenali oleh suatu Nilai header Berikutnya beda. Sebagai yang digambarkan contoh ini, suatu IPV6 paket boleh membawa nol, satu, atau lebih luas headernya, masing-masing yang dikenali oleh next header dari header yang terdahulu:
+---------------+------------------------
| IPv6 header | TCP header + data
| |
| Next Header = |
| TCP |
+---------------+------------------------
+---------------+----------------+------------------------
| IPv6 header | Routing header | TCP header + data
| | |
| Next Header = | Next Header = |
| Routing | TCP |
+---------------+----------------+------------------------
+---------------+----------------+-----------------+-----------------
| IPv6 header | Routing header | Fragment header | fragment of TCP
| | | | header + data
| Next Header = | Next Header = | Next Header = |
| Routing | Fragment | TCP |
+---------------+----------------+-----------------+-----------------
Dengan satu perkecualian, perluasan header tidaklah diuji atau diproses dengan nodes manapun sepanjang suatu alur penyerahan paket, sampai paket menjangkau
node( atau masing-masing satuan node, di dalam kasus multicast)
yang dikenali di dalam destination address header IPV6.
Demultiplexing normal pada next header IPV6 meminta modul untuk memproses perluasan header pertama,atau header upper-layer jika tidak ada perluasan header ditampilkan. Muatan Dan Ilmu semantik dari tiap perluasan header menentukan apakah atau bukan untuk memulai next header. Oleh karena itu, perluasan header harus diproses dengan ketat agar supaya mereka nampak di paket; sebuah penerima harus tidak, sebagai contoh, meneliti melalui suatu paket mencari sebuah jenis tertentu perluasan header dan memproses header prior itu sebelum pemrosesan terdahulu. Perkecualian menunjuk kepada paragraf yang terdahulu adalah Hop-By-Hop option header,dimana membawa informasi yang harus diuji dan diproses oleh tiap-tiap node sepanjang suatu alur penyerahan paket, termasuk
source dan destination nodes. Hop-By-Hop option header,
ketika ditampilkan, harus dengan seketika mengikuti header IPV6. Kehadiran nya
ditandai oleh nilai nol di [dalam] Bidang next header pada header IPV6.
Keberadaannya ditandai oleh nilai nol pada header field berkutnya dari Ipv6 header. Jika, sebagai hasil pengolahan header, suatu node diperlukan untuk berproses kepada header yang berikutnya tetapi header yang berikutnya menilai header yang sekarang adalah yang tak dikenali oleh node, header harus membuang paket dan mengirimkan suatu ICMP Pesan Masalah Parameter kepada sumber paket, dengan suatu ICMP Nilai Kode 2 (" Jenis header Berikutnya yang tak dikenali ") dan ICMP pointer field berisi offset nilai yang tak dikenali di dalam paket yang asli. Tindakan yang sama harus diambil jika Suatu node menghadapi suatu nilai header berikutnya nol dari semua header lain dibanding header pada IPV6.
Masing-Masing header perluasan adalah suatu bilangan bulat berbagai 8 komposisi 8 octet , di dalam memesan untuk mempertahankan 8-octet kelurusan header yang berikut. Multi-Bidang Komposisi 8 octet di dalam masing-masing header perluasan dibariskan pada batasan-batasan alami, yaitu., bidang lebar n komposisi music 8 suara ditempatkan pada suatubilangan bulat berbagai n komposisi music 8 suara dari start header, untuk n= 1,2, 4, atau 8.
Suatu implementasi IPV6 penuh meliputi implementasi mengikuti header perluasan :
Hop-by-Hop Options
Routing (Type 0)
Fragment
Destination Options
Authentication
Encapsulating Security Payload
2.4.1. Pesan Header Perluasan (Extension Header Order)
Ketika lebih dari header perluasan digunakan pada paket yang sama adalah dianjurkan header-header itu nampak pada pesan yang berikut:
IPv6 header
Hop-by-Hop Options header
Destination Options header (catatan 1)
Routing header
Fragment header
Authentication header (catatan 2)
Encapsulating Security Payload header (note 2)
Destination Options header (catatan 3)
upper-layer header
catatan 1: pilihan untuk diproses oleh tujuan yang pertama itu nampak IPV6 field Alamat Tujuan ditambah tujuan yang berikut yang ditampilkan pada Routing Header.
catatan 2: rekomendasi tambahan mengenai pesan yang berhubungan dengan Pengesahan dan Encapsulasi Security Payload Header disampaikan dalam [ RFC-1827].
Catatan 3 pilihan untuk diproses hanya tujuan akhir dari paket.
Masing-Masing perluasan header terjadi paling banyak sekali, kecuali header Pilihan Tujuan dapat terjadi paling banyak dua kali (sekali ketika sebelum Routing Header dan yang kedua sebelum header lapisan atas).
Jika header lapisan atas ( upper-layer header) adalah header IPV6 lain ( di dalam kasus IPV6 menjadi tunnel di atas encapsulasi IPV6), mungkin saja diikuti olehheader perluasan sendiri, yang secara terpisah tunduk kepada pesan yang sama.
Jika dan ketika header perluasan lain digambarkan, batasan pemesanan mereka sehubungan dengan header yang telah ditampilkan di atas harus ditetapkan.
IPV6 nodes harus menerima dan mencoba untuk memproses header air perluasan di manapun pesanan terjadi dalam paket yang sama, kecuali Hop-By-Hop header Pilihan yang mana terbatas untuknampak dengan seketika setelah suatu IPV6 header. Meskipun begitu, betul-betul dinasehatkan agar sumber paket IPV6 bertahan pada pesan yang direkomendasikan sampai kecuali jika spesifikasi yang berikut meninjau kembali rekomendasi tersebut.
2.4.2. Pilihan (options)
Dua di antara header perluasan yang didefinisikan sebagai Hop-By-Hop header Pilihan dan header pilihan Tujuan, membawa suatu variabel dengan tipe angka disebut sebagai type-length-value ( Type Length Value) yang disandikan " pilihan", dengan format berikut:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type 8-bit identifier of the type of option.
Opt Data Len 8-bit unsigned integer. Length of the Option
Data field of this option, in octets.
Option Data Variable-length field. Option-Type-specific
data.
Urutan pilihan di dalam suatu header harus diproses dengan keras di dalam pesan yang nampak pada header. Jenis Pilihan identifiers secara internal disandikan melalui highest-order 2 bits menetapkan tindakan yang harus diambil jika proses nodes IPV6 tidak mengenali Tipe pilihan:
00- melampaui;menghapuskan pilihan ini dan melanjut memproses header tersebut.
01- membuang paket [itu].
10- membuang paket, dengan mengabaikan ya atau tidaknya
Alamat Tujuan dari paket yaitu suatu multicast menunjuk, mengirimkan
suatu ICMP Parameter, Kode 2, pesan kepada milik paket
Alamat Sumber, menunjuk Pilihan yang tak dikenali tipe pilihan.
11- membuang paket [itu] dan, hanya jika Tujuan paket
Alamat bukanlah suatu multicast menunjuk, mengirimkan suatu ICMP Parameter
Masalah, Kode 2, pesan kepada Alamat Sumber paket,
menunjuk Jenis Pilihan yang tak dikenali.
Third-Highest-Order bit Jenis Pilihan menetapkan apakah data pilihan menyangkut pilihan itu dapat berubah en-route kepada tujuan paket akhir. Ketika suatu header Pengesahan hadir di paket, untuk pilihan data manapun siapapun boleh berubah,en-route keseluruhan field pilihan data harus diperlakukan sebagai komposisi 8 oktet nisli 0 ketika komputasi atau membuktikan keaslian paket itu.
0- Pilihan Data tidak berubah en-route
1- Pilihan Data boleh berubah en-route
Pilihan individu mungkin punya kebutuhan kelurusan spesifik, untuk memastikan bahwa multi-octet nilai-nilai di dalam Bidang Data Pilihan jatuh terpasang batasan-batasan alami. Kebutuhan Kelurusan dari suatu pilihan adalah yang ditetapkan menggunakan notasi xn+y, maksud/arti jenis pilihan harus nampak pada suatu bilangan bulat berbagai x komposisi 8 suara dari start header lebih y komposisi music 8 suara. Sebagai contoh:
2n berarti 2-octet manapun offset dari start header.
8n+2 [alat/ makna] 8-octet offset dari start header manapun lebih 2 dari
komposisi 8 suara.
Ada dua pilihan lapisan digunakan ketika diperlukan untuk membariskan pilihan yang berikut dan untuk memperpanjang itu berisi header dari suatu tentang 8 komposisi 8 octet. Pilihan Lapisan ini harus dikenali oleh semua implementasi IPV6.
Pad1 : Pilihan
+-+-+-+-+-+-+-+-+
| 0|
+-+-+-+-+-+-+-+-+
CATATAN! format Pad1 Pilihan adalah suatu kasus khusus dimana pengerjaannya bukan mempunyai panjang dan field nilai.
Pilihan pad1 digunakan untuk memasukkan/menyisipkan satu komposisi 8 octet ke dalamArea Pilihan suatu header. Jika komposisi 8 suara lebih dari satu lapisan maka diperlukan Pad n pilihan.
Pad n Pilihan ( Kebutuhan Kelurusan: tidak ada)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------
| 1| Memilih Data Len| Data Pilihan
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------
Pad n Pilihan digunakan untuk memasukkan/menyisipkan dua atau lebih komposisi music 8 suara lapisan ke dalam Area Pilihan header. Karena lapisan N komposisi 8 octet,Memilih field Data Len berisi nilai N-2, dan Pilihan data terdiri dari N-2 komposisi 8 octet nilai nol.
2.4.3 Hop-By-Hop header Pilihan
Hop-By-Hop header pilihan digunakan untuk membawa informasi opsional bahwa harus diuji oleh tiap-tiap nodes sepanjang suatu alur penyerahan paket. Hop-By-Hop header Pilihan dikenali oleh suatu Nilai header berikutnya Nol pada header IPV6, dan mempunyai format yang berikut:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header berikutnya | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .
| |
. .
. Options / pilihan .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header Berikutnya 8-Bit Selektor. Identifikasi header dengan seketika
mengikuti pilihan Hop-By-Hop header
Gunakan nilai-nilai yang sama sebagai field IPV4 Protokol [ RFC-1700 et seq.].
Hdr Ext Len 8-bit bilangan bulat tidak ditandai Panjangnya pilihan
Hop-By-Hop header di dalam 8-octet unit, belum
termasuk yang pertama 8 komposisi 8 octet.
Pilihan Variable-Length menyudahi Hop-By-Hop header
Pilihan adalah suatu bilangan bulat berbagai 8
komposisi 8 octet.
Sebagai tambahan terhadap Pad1 Dan Pad n Pilihan menetapkan bagian 4.2, hop-by-hop pilihan yang berikut digambarkan:
Jumbo Payload option ( Kebutuhan Kelurusan: 4N+ 2)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 194 | Memilih Data Len=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jumbo Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jumbo Payload digunakan untuk mengirimkan IPV6 paket dengan payload lebih panjang dibanding 65,535 komposisi 8 octet. Jumbo Payload Length adalah panjang paket di dalam komposisi 8 octet, tidak termasuk IPV6 header tetapi mencakup Hop-By-Hop header pilihan ; dimana harus lebih besar dari 65,535. Jika suatu paket diterima dengan suatu Jombo Payload, yang berisi suatu panjang dari Jumbo payload kurang dari atau sepadan dengan 65,535, suatu ICMP Pesan Parameter, Kode 0, harus dikirim kepada sumber paket, menunjuk ke high-order komposisi 8 octet yang cacat pada panjang field pada Jumbo Payload.
Field panjang Jumbo Payload di dalam IPV6 header harus mulai dari nol di dalam tiap-tiap paket yang membawa Pilihan Jumbo Payload tersebut. Jika sebuah paket diterima dengan suatu Jumbo Payload yang sah menyajikan dan suatu IPV6 tidak nol padap field Jumbo Payload, suatu ICMP Masalah Parameter.
Pesan Masalah Parameter, Kode 0, harus dikirim kepada milik paket sumber, menunjuk komposisi 8 octet yang pertama dari header Fragmen.
Suatu implementasi yang tidak mendukung Jumbo Payload tidak bisa mempunyai penghubung ke mata-mata rantai MTU dimana adalah lebih besar dari 65,575 ( 40 komposisi 8 octet IPV6 header yang lebih dari 65,535 komposisi 8 octet Payload).
2.4.4 Menaklukkan header (Routing Header)
Header Penaklukan digunakan oleh suatu sumber IPV6 untuk mendaftar satu atau lebih node intermediate yang“dikunjungi" di perjalanan ke suatu paket milik tujuan. Fungsinya adalah sangat serupa ke Rute Sumber pilihan IPV4'S. Header Penaklukan dikenali oleh suatu Nilai header berikutnya yaitu 43 pada header berikutnya dan mempunyai format yang berikut:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header berikutnya 8-Bit Selektor. Identifikasi jenis header
yang dengan seketika menaklukkan header
berikutnya
Gunakan nilai-nilai yang sama pada field IPV4 Protokol
[ RFC-1700 et seq.].
Hdr Ext Len 8-bit bilangan bulat Positif. Panjangnya Routing header dalam 8-octet unit, belum termasuk 8 octets pertama.
Routing Type 8-Bit identifier varian routing header tertentu.
Segmen Left 8-bit bilangan bulat tidak ditandatangani. Jumlah rute segmen yang tersisa, yaitu., jumlah daftar eksplisit node yang perlu dikunjungi sebelum mencapai tujuan yang akhir.
Type-Specific Data Variable-Length Bidang, tentang format yang ditentukan oleh Routing type, dan panjang dari suatu routing header yang lengkap adalah panjang suatu bilangan bulat kelipatan dari 8 octets
Jika, sedang memproses menerima sebuah paket, suatu node menemukan routing header dengan nilai yang tidak dikenali dari suatu routing type, perilaku yang diperlukan node tergantung pada nilai Segmeny Left field, seperti:
Jika Segmen Left adalah nol, node harus mengabaikan routing header dan mulai proses header yang berikutnya di paket, jenis siapa dikenali oleh header Yang berikutnya di dalam routing header.
Jika Segmen Left adalah tidak nol, node harus membuang paket itu dan mengirimkan suatu ICMP Parameter Problem, Kode 0, pesan kepada pemilik paket di alamat sumber, menunjuk routing type yang tidak dikenali.
Jika sebuah proses routing header dari paket penerima, semuah intermediate node menilai bahwa paket ini dikirimkan pada suatu link milih MTU yang lebih kecil dari ukuran paket, node harus menghilangkan paket dan mengirim sebuah ICMP Packet Too Big message kepada paket Alamat Sumber.
Jenis 0 Routing header mempunyai format yang berikut:
Next Header Hdr Ext Len Routing Type=0 Segments Lef
Reserved
Address[1]
Address[2]
Address[n]
Next header 8-Bit Selektor. Identifikasi jenis header
dengan seketika berikut routing header.
Menggunakan nilai-nilai yang sama sebagai IPV4 Protokol Field
[ RFC-1700 et seq.].
Hdr Ext Len 8-bit bilangan bulat positif. Panjangnya
Routing headerdi (dalam) 8-octet unit, belum termasuk 8 octets pertama. Karena Jenis 0 routing header, Hdr Ext Len harus sama dengan dua kali jumlah alamat di header.
Routing Type 0.
Segmen Left 8-bit bilangan bulat positif. Jumlah rute
segmen yang tersisa yaitu., jumlah explisit yang didaftarkan di intermediate nodes yang perlu dikunjungi sebelum mencapai tujuan yang akhir.
Reserved 32-bit reserved field. Memberikan nilai nol pada transmisi; mengabaikan saat menerima.
Address[1..N] vektor 128-bit menunjuk, nomor 1 untuk n.
Multicast Addresses harus tidak nampak dalam suatu routing header type 0, atau
di dalam IPV6 Bidang Alamat Tujuan suatu paket membawa suatu routing header type 0.
Sebuah routing header tidak diperiksa ato diproses sampai mencapai node yang di identifikasi di dalam Alamat Tujuan pada IPv6 header.
Cara Kerja ditunjukan pada algoritma di bawah ini :
if Segments Left = 0 {
proceed to process the next header in the packet, whose type is
identified by the Next Header field in the Routing header
}
else if Hdr Ext Len is odd or greater than 46 {
send an ICMP Parameter Problem, Code 0, message to the Source
Address, pointing to the Hdr Ext Len field, and discard the
packet
}
else {
compute n, the number of addresses in the Routing header, by
dividing Hdr Ext Len by 2
if Segments Left is greater than n {
send an ICMP Parameter Problem, Code 0, message to the Source
Address, pointing to the Segments Left field, and discard the
packet
}
else {
decrement Segments Left by 1;
compute i, the index of the next address to be visited in
the address vector, by subtracting Segments Left from n
if Address [i] or the IPv6 Destination Address is multicast {
discard the packet
}
else {
swap the IPv6 Destination Address and Address[i]
if bit i of the Strict/Loose Bit map has value 1 and the
new Destination Address is not the address of a neighbor
of this node {
send an ICMP Destination Unreachable -- Not a Neighbor
message to the Source Address and discard the packet
}
else if the IPv6 Hop Limit is less than or equal to 1 {
send an ICMP Time Exceeded -- Hop Limit Exceeded in
Transit message to the Source Address and discard the
packet
}
else {
decrement the Hop Limit by 1
resubmit the packet to the IPv6 module for transmission
to the new destination
}
}
}
}
Sebagai suatu contoh efek dari algoritma di atas, mempertimbangkan kasus suatu Sumber Node S mengirimkan suatu paket ke Tujuan Node D, menggunakan suatu routing header untuk menyebabkan paket itu untuk dikirimkan via intermediate Nodes pohon/bengkak urat] I1, I2, dan I3. Nilai-Nilai relevan IPV6 header dan routing header pada setiap segmen dari jalur pengiriman sebagai berikut:
As the packet travels from S to I1:
Source Address = S Hdr Ext Len = 6
Destination Address = I1 Segments Left = 3
Address[1] = I2
Address[2] = I3
Address[3] = D
As the packet travels from I1 to I2:
Source Address = S Hdr Ext Len = 6
Destination Address = I2 Segments Left = 2
Address[1] = I1
Address[2] = I3
Address[3] = D
As the packet travels from I2 to I3:
Source Address = S Hdr Ext Len = 6
Destination Address = I3 Segments Left = 1
Address[1] = I1
Address[2] = I2
Address[3] = D
As the packet travels from I3 to D:
Source Address = S Hdr Ext Len = 6
Destination Address = D Segments Left = 0
Address[1] = I1
Address[2] = I2
Address[3] = I3
2.4.5 Fragment Header
Fragment Header digunakan oleh suatu IPV6 sumber untuk mengirimkan paket lebih besar daripada memasukan pada jalur MTU menuju tujuannya. ( Catatan: tidak sama dengan IPV4, Fragmentasi di IPV6 dilakukan hanya oleh nodes sumber, bukan oleh routers sepanjang suatu alur pengiriman paket-- lihat bagian 5.) Fragment Header dikenali oleh suatu nilai header berikutnya deng nilai 44 di dalam pemrosesan header, dan mempunyai format yang berikut:
Next Header Reserved Fragment Offset Res M
Identification
Next Header 8-bit selector. Identifies the initial header type of the Fragmentable Part of the original packet (defined below). Uses the same values as the IPv4 Protocol field [RFC-1700 et seq.].
Reserved 8-bit reserved field. Initialized to zero for
transmission; ignored on reception.
Fragment Offset 13-bit unsigned integer. The offset, in 8-octet
units, of the data following this header,
relative to the start of the Fragmentable Part
of the original packet.
Res 2-bit reserved field. Initialized to zero for
transmission; ignored on reception.
M flag 1 = more fragments; 0 = last fragment.
Identification 32 bits. See description below.
Dalam pengiriman paket yang terlalu besar untuk diterima dalam MTU sebagai jalur tujuan, sebuah node sumber boleh membagi paket tersebut menjadi fragment-fragment dan mengirim setiap fragment sebagai paket terpisah, untuk dikembalikan lagi di receiver.
Setiap paket yang di fragmentasi, node sumber memunculkan sebuah nilai identifikasi. Nilai tersebut harus berbeda dengan fragmentasi paket yang sudah dikirim sama dengan Alamat sumber dan Alamat tujuan. Jika routing header menunjuk, Alamat tujuan akan menganggap ini adalah tujuan akhir.
* " baru-baru ini" berarti di dalam yang maksimum yang mungkin seumur hidup suatu paket,mencakup waktu pemindahan dari sumber ke tujuan dan waktu yang habis digunakan untuk menunggu reassembly dengan fragment lain dari paket yang sama. Bagaimanapun, itu tidaklah diperlukan bahwa suatu node sumber mengetahui yang maksimum umur hidup paket. Melainkan, itu mengira bahwa kebutuhan itu dapat dijumpai dengan pemeliharaan Nilai Identifikasi secara sederhana, 32- bit, " berputar balik" waktu masing-masing ditambahkan suatu paket harus terbagi-bagi. Itu adalah suatu pilihan implementasi apakah untuk memelihara counter tunggal untuk node atau berbagai counter, e.g., masing-masing dapat satu alamat sumber node mungkin, atau masing-masing dapat satu aktif kombinasi( alamat sumber, alamat tujuan).
Awal, paket tidak terbagi-bagi besar dikenal sebagai
" paket yang asli", dan itu dipertimbangkan untuk terdiri dari dua bagian,
seperti yang digambarkan:
paket asli:
Unfragmentable Part Fragmentable Part
Unfragmentable Part terdiri dari IPV6 header ditambah perluasan header yang harus diproses oleh node dan mengarahkan kepada tujuan, itu adalah, semua header yang ke atas dan termasuk routing header, selain itu Hop-By-Hop header pilihan, selain itu tidak ada perluasan header.
Fragmentable Part terdiri dari sisa dari paket, itu adalah, perluasan header yang kebutuhan diproses hanya oleh node tujuan akhir, ditambah upper layer header dan data.
Fragmentable Part dari paket yang asli adalah dibagi menjadi fragment-fragment, masing-masing, kecuali mungkin yang terakhir itu (" rightmost") satu, menjadi bilangan bulat kelipatan dari 8 octets. Fragment dipancarkan terpisah " fragment packets" seperti yang digambarkan:
paket asli:
Unfragmentable Part First Fragment Second Fragment ……… Last Fragment
fragment packets:
Unfragmentable Part Fragment Header First Fragment
Unfragmentable Part Fragment Header Second Fragment
o
o
o
Unfragmentable Part Fragment Header Last Fragment
Masing-Masing paket fragment adalah terdiri atas:
Unfragmentable Part dari paket yang asli, dengan Panjangnya Muatan IPV6 header yang asli berubah untuk berisi panjang paket fragment yang ini saja ( tidak termasuk panjang IPV6 header sendiri), dan bidang header yang berikutnya dari header terakhir dari unfragmentable part yang diubah ke 44.
Isi Fragment Header :
Nilai HeaderYang berikutnya yang mengidentifikasi header yang pertama dari fragmentable part dari paket yang asli.
Suatu Offset Fragmen yang berisi offset fragment, di dalam 8-octet unit, sehubungan dengan start fragmentable part dari paket yang asli. Fragmen Offset yang pertama ("leftmost") fragment adalah 0.
Nilai flag M adalah 0 jika fragment adalah yang terakhir ("rightmost") satu, selain itu nilai flag M adalah 1.
Nilai Identifikasi dihasilkan untuk paket yang asli.
Fragment itu sendiri
Panjangnya fragmen harus dipilih seperti yang menghasilkan
paket fragmen yang cocok di dalam MTU dari alur kepada paket-paket tujuan.
Di tujuan, fragment paket dikumpulkan kembali ke dalam format yang asli, seperti yang digambarkan:
Paket asli yang dikumpulkan kembali:
Unfragmentable Part Fragmentable Part
Aturan yang berikut mengurus reassembly:
Suatu paket asli dikumpulkan kembali hanya dari paket fragmen yang
mempunyai Alamat Sumber yang sama, Alamat Tujuan, dan Fragmen
Identifikasi.
Bagian header berikutnya yang merupakan bagian terakhir yang tidak bisa dibagi-bagi diperoleh dari bagian header yang berikutnya lebih dulu sebagai bagian awal dari header fragmen. Payload Length yang dikumpulkan kembali dihitung dari panjang bagian yang tidak bisa dibagi-bagi lagi. Sebagai contoh, suatu rumusan untuk menghitung Payload Length paket asli yang dikumpulkan kembali adalah:
PL.ORIG= PL.FIRST- FL.FIRST- 8+ ( 8* FO.LAST)+ FL.LAST
[di mana/jika]
PL.ORIG= Bidang Payload Length paket dikumpulkan kembali.
PL.FIRST= Bidang Payload Length paket fragmen pertama.
FL.FIRST= panjangnya fragmen yang mengikuti bagian header Fragmen
paket fragmen pertama.
FO.LAST= Bidang Offset Fragmen header Fragmen yang bertahan/berlangsung paket fragmen.
FL.LAST= panjangnya fragmen yang mengikuti header Fragmen paket fragmen.
Yang bisa membagi-bagi Bagian dari paket yang dikumpulkan kembali dibangun
dari fragmen yang mengikuti header Fragmen itu pada setiap paket fragmen.
Panjang fragmen masing-masing dihitung oleh pengurangan dari Payload Length paket panjang header antara header IPV6 dan fragmennya sendiri.HeaderFragmen tidak terdapat di bagian akhir, paket.dikumpulkan kembali.
Kesalahan yang berikut Kondisi-Kondisi boleh [muncul/bangkit] ketika pengumpulan kembali paket terbagi-bagi. Jika fragmen tidak cukup diterima untuk melengkapi reassembly paket di dalam 60 detik yang pertama kali datang dari paket tersebut dilakukan reassembly semua fragmen yang telah diterima untuk paket harus dibuang. Jika fragmen yang pertama (dengan suatu Offset Fragmen nol) telah diterima, suatu ICMP Time Exceeded fragmen melakukan Reassembly Time Exceed yang memberikan pesan seharusnya dikirim ke sumber fragmen itu .
Jika panjang suatu fragmen diperoleh dari fragmen milik paket Bidang Payload Length, bukanlah 8 komposisi music 8 suara dan M Flag fragmen itu adalah 1, kemudian fragmen itu harus dibuang dan suatu ICMP Masalah Parameter, Kode 0, pesan harus dikirim kepada sumber fragmen, menunjuk Payload length field dari paket fragmen.
Jika panjangnya dan offset suatu fragmen sedemikian hingga Payload length field paket mengumpulkan kembali dari yang fragmen akan melebihi 65,535 komposisi music 8 suara, kemudian fragmen itu harus dibuang dan suatu ICMP Masalah Parameter, Kode 0, pesan harus dikirim kepada sumber fragmen, menunjuk Bidang Offset paket fragme itu.
Kondisi-Kondisi yang berikut tidaklah diharapkan untuk terjadi, tetapi bukanlah kesalahan yang dipertimbangkan jika mereka lakukan Nomor; Jumlah Dan Isi header yang terdahulu Fragmen Header dari fragmen paket yang asli sama yang berbeda boleh berbeda. Apapun juga header berada sebelum fragmen.
Header pada setiap paket fragmen, diproses ketika paket tiba, sebelum antri fragmen itu untuk reassembly. Header itu di dalam Offset nol paket fragmen ditahan paket yang dikumpulkan kembali itu.
Header yang berikutnya menilai header dari fragmen yang berbeda dengan fragmen paket asli yang sama boleh berbeda. Hanya nilai dari Offset nol paket fragmen digunakan untuk reassembly.
2.4.6 Destinations optional Header
Optional header digunakan untuk membawa informasi opsional kebutuhan yang diuji hanya oleh suatu tujuan paket nodes.
Optional header dikenali oleh suatu Nilai header berikutnya 60 di (dalam) header yang dengan seketika terdahulu, dan mempunyai format yang berikut:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header berikutnya 8-Bit Selektor. Identifikasi jenis header yang mengikuti optional header. Gunakan nilai-nilai yang sama [sebagai/ketika] IPV4 Bidang Protokol [ RFC-1700 et seq.].
Hdr Ext Len 8-bit bilangan bulat tidak ditandai. Panjangnya PEmi di (dalam) 8-octet unit, belum termasuk yang pertama 8 komposisi music 8 suara.Pilihan Variable-Length Bidang, tentang panjangnya . seperti (itu) [bahwa/yang] melengkapi;menyudahi Serudukan/Palu air Pilihan Tujuan adalah suatu bilangan bulat berbagai 8 komposisi music 8 suara [panjang/lama]. Isi satu atau lebih Pilihan TLV-encoded, [seperti/ketika] diuraikan di (dalam) bagian 4.2.Satu-Satunya pilihan tujuan menggambarkan dokumen ini adalah Pad1dan Padn Pilihan menetapkan bagian 4.2.
Catat bahwa ada dua jalan mungkin untuk menandai tujuan pemilihan informasi di suatu paket IPV6: baik sebagai suatu pilihan di destination optional header , atau sebagai suatu header perluasan terpisah. Header fragmen dan Header Pengesahan adalah contoh yang paling mendekati. Pendekatan yang mana dapat digunakan tergantung pada tindakan apa yang diinginkan untuk suatu [tujuan yang tidak memahami pemilihan informasi.
o jika yang diinginkan adalah tindakan untuk tujuan membuang paket dan, jika hanya Alamat Tujuan paket bukanlah suatu multicast menunjuk, mengirimkan suatu ICMP Tak mengenali Pesan Jenis untuk Alamat Sumber paket, kemudian informasi mungkin yang disandikan baik sebagai suatu header terpisah atau sebagai suatu pilihan .
Pemilihan optional header jenis apa mempunyai nilai 11 dalam highest-order dua puluh lima sen. Pilihan boleh tergantung pada faktor yang mengambil lebih sedikit komposisi music 8 suara, atau hasil yang lebih baik, penguraian lebih efisien.
o bila ada lain tindakan diinginkan, informasi harus disandikan sebagai suatu pilihan di dalam header tujuan mempunyai nilai 00, 01, atau 10 dalam nya highest-order dua puluh lima sen, penetapan tindakan yang diinginkan ( lihat bagian 4.2).
2.4.7 Tidak (ada) Header berikutnya
Nilai 59 Bidang header yang berikutnya dari suatu IPV6 atau manapun header perluasan menunjukkan bahwa tidak ada apapun berikut yang header. Jika Payload length field header IPV6 menandai (adanya) kehadiran komposisi music 8 suara yang lampau ujung suatu header Berikutnya yang berisi 59, komposisi music 8 suara itu harus diabaikan, dan diteruskan tanpa perubahan jika paket disampaikan.
2.5. Masalah Ukuran Paket
IPV6 memerlukan bahwa tiap-tiap mata rantai di (dalam) internet mempunyai suatu MTU 576 komposisi music 8 suara atau lebih besar. Pada mata rantai manapun yang tidak bisa menyampaikan 576-octet paket di dalam satu potongan, pemecahan menjadi kepingan link-specific dan reassembly harus yang disajikan pada suatu lapisan di bawah IPV6.
Hubungkan bahwa mempunyai suatu MTU configurable ( sebagai contoh, PPP mata rantai [ RFC-1661]) harus yang diatur untuk mempunyai suatu MTU sedikitnya 576 komposisi music 8 suara itu direkomendasikan bahwa suatu MTU lebih besar diatur, untuk mengakomodasi mungkin encapsulations ( yaitu. pembangunan penghubung) tanpa mengakibatkan pemecahan menjadi kepingan. betul-betul direkomendasikan IPV6 Alur pesawat itu MTU Penemuan [ RFC-1191], dalam rangka menemukan dan mengambil keuntungan dari alur dengan MTU lebih besar dari 576 komposisi music 8 suara. Bagaimanapun, suatu IPV6 minimal implementasi ( e.g., di (dalam) suatu sepatu boot ROM) [yang] bisa dipastikan membatasi [dirinya] sendiri untuk mengirimkan paket tidak (ada) lebih besar dari 576 komposisi music 8 suara, dan menghilangkan implementasi Alur MTU Penemuan.
Untuk mengirimkan suatu paket lebih besar dari suatu alur MTU, node boleh menggunakan IPV6 Header Fragmen untuk membagi-bagi paket itu di sumber dan mengumpulkan kembali di tempat tujuan. Bagaimanapun, pemecahan menjadi kepingan manapun aplikasi yang bias melakukan penyesuaian paket nya untuk cocok alur yang terukur MTU ( yaitu., hingga [menuju] ke 576 komposisi music 8 suara). Suatu node harus mampu menerima suatu paket yang terbagi-bagi, setelah reassembly, adalah sama besar seperti 1500 komposisi music 8 suara, mencakup header IPV6 itu. Suatu node dapat menerima paket yang terbagi-bagi untuk mengumpulkan kembali lebih dari 1500 komposisi music 8 suara.
Bagaimanapun, suatu node tidak harus mengirimkan fragmen yang mengumpulkan kembali suatu ukuran lebih besar dari 1500 komposisi music 8 suara kecuali jika mempunyai pengetahuan tegas/eksplisit bahwa destination dapat mengumpulkan kembali ukuran paket itu.
Sebagai jawaban atas suatu IPV6 paket yang dikirim untuk suatu IPV4 ( yaitu., suatu paket yang mengalami terjemahan dari IPV6 ke IPV4), memulai node IPV6 boleh menerima suatu Paket besar pesan ICMP pelaporan suatu NEXT-HOP MTU kurang dari 576.Node IPV6 bukan diperlukan untuk mengurangi ukuran paket untuk kurang dari 576, tetapi harus meliputi suatu header Fragmen dalam paket itu sedemikian sehingga IPV6-TO-IPV4 penerjemahan dapat memperoleh suatu Identifikasi untuk menggunakan menghasilkan IPV4 fragmen. Catat bahwa ini berarti Payload field mungkin telah untuk mengurangi 528 komposisi music 8 suara ( 576 kurang 40) untuk header IPV6 dan 8 untuk header Fragmen), dan lebih kecil masihkah jika perluasan header tambahan digunakan.
2.6. Flow Label
24-Bit Bidang arus Label di dalam header IPV6 digunakan oleh sumber ke label paket itu di mana hal itu membutuhkan penanganan khusus dengan IPV6 penerus, seperti mutu [jasa;layanan]. Aspek/Pengarah IPV6 ini adalah, ketika menulis,namun bersifat percobaan dan tunduk kepada perubahan sesuai kebutuhan untuk arus mendukung Internet menjadi lebih jelas. Penghuni Atau Penerus yang tidak mendukung fungsi Arus Bidang Label diperlukan untuk menetapkan bidang itu nol ketika permulaan suatu paket, menyampaikan bidang tanpa perubahan ketika penyampaian suatu paket, dan mengabaikan bidang ketika menerima suatu paket.
Suatu arus adalah suatu urutan paket mengirim dari sumber tertentu untuk sesuatu tertentu ( unicast atau multicast) di mana tujuan sumber menginginkan penanganan khusus oleh penerus. Sifat alami disampaikan kepada penerus oleh suatu kendali protokol, seperti suatu protokol reservasi sumber daya, atau informasi di dalam arus paket mereka, e.g., di (dalam) suatu hop-by-hop pilihan.Detil . seperti (itu) protokol kendali atau pilihan adalah di luar lingkup tentang dokumen ini. Mungkin ada berbagai arus aktif dari suatu sumber ke tujuan, baik seperti lalu lintas yang tidak dihubungkan dengan arus manapun.
Suatu arus dengan uniknya dikenali oleh kombinasi suatu sumber menunjuk label arus tidak nol. Paket yang bukan kepunyaan suatu arus membawa label nol.
Suatu label arus ditugaskan untuk suatu arus oleh node sumber arus. Label baruarus harus terpilih ( pseudo-randomly) dan yang seragam mencakup dari 1 ke FFFFFF. Tujuan alokasi yang acak untuk membuat satuan bit manapun di dalam Bidang Label Arus yang pantas untuk penggunaan suatu dengan penerus.
Semua paket yang kepunyaan arus yang sama harus dikirim dengan alamat sumber yang sama, alamat tujuan, prioritas, dan label arus. Jika manapun paket itu meliputi semua Hop-By-Hop optional header, kemudian mereka semua harus dimulai dengan Hop-By-Hop optional header yang sama. Bila ada paket itu semua meliputi suatu header, kemudian mereka semua harus dimulai dengan muatan/indeks yang sama dalam semua perluasan
Header yang atas ke dan termasuk routing header. Jika suatu pelanggaran dideteksi, haruslah dilaporkan kepada sumber oleh suatu ICMP Pesan Masalah Parameter, Kode 0, menunjukkan high-order komposisi music 8 suara Bidang Arus Label ( yaitu., offset 1 di dalam IPV6 paket).
Penerus bebas untuk " opportunistically" yang disediakan flow-handling status untuk arus manapun, bahkan ketika tidak ada informasi penetapan arus telah disajikan via suatu protokol kendali, suatu hop-by-hop pilihan, atau lain [alat/ makna]. Sebagai contoh, [atas/ketika] menerima suatu paket dari sumber tertentu dengan suatu label arus tidak nol yang tak dikenal, suatu penerus boleh memproses header IPV6 nya dan perluasan header manapun perlu seolah-olah label arus adalah nol. Bahwa pengolahan akan menentukan next-hop alat penghubung, dan mungkin tindakan lain, seperti pembaharuan hop-by-hop pilihan, mempercepat tongkat penunjuk dan menunjuk suatu Routing header, atau memutuskan bagaimana cara antri paket berdasar pada Prioritas nya Bidang. Penerus boleh kemudian memilih untuk " ingat" hasil itu semua memproses langkah-langkah dan tempat yang menyembunyikan informasi, menggunakan alamat sumber sebagai kunci tempat menyembunyikan. Paket yang berikut dengan sumber yang sama menunjuk dan arus label boleh kemudian ditangani dengan menunjuk kepada informasi yang cache.
Flow-handling menyatakan bahwa disediakan dengan tegas, untuk contoh oleh suatu protokol kendali atau suatu hop-by-hop pilihan, harus ditetapkan sebagai bagian dari spesifikasi yang tegas/eksplisit membangun mekanisme; mungkin melebihi 6 detik.
Ketika suatu node stop dan start kembali itu harus saksama bukan untuk menggunakan suatu label arus bahwa itu mungkin telah menggunakan untuk suatu arus. Ini mungkin yang terpenuhi dengan perekaman pemakaian label arus stabil sedemikian sehingga dapat diingat label arus sampai maksimum tentang segala mungkin sebelumnya arus yang dibentuk telah berakhir ( sedikitnya 6 detik arus membangun mekanisme dengan umur hidup lebih panjang mungkin telah digunakan). Jika waktu yang minimum untuk node kembali, waktu itu dapat dikurangi dari penantian yang perlu permulaan untuk mengalokasikan label arus.
Tidak ada kebutuhan bahwa semua, atau bahkan kebanyakan, paket mengalir, yaitu membawa label arus tidak nol. Pengamatan ini ditempatkan di sini untuk mengingatkan para perancang protokol dan pelaksana untuk mengasumsikan cara lainnya. Sebagai contoh,adalah bodoh untuk mendisain suatu penerus yang bersifat cukup hanya jika kebanyakan paket kepunyaan arus, atau untuk mendisain suatu rencana tekanan header yang hanya bekerja/lancar pada [atas] paket itu.
2.7. Prioritas
4-Bit Bidang Prioritas di (dalam) IPV6 header memungkinkan suatu sumber untuk mengidentifikasi prioritas penyerahan yang diinginkan tentang paket nya , sehubungan dengan lain paket dari sumber yang sama [itu]. Nilai-Nilai Prioritas dibagi ke dalam dua cakupan: Nilai 0 melalui/sampai 7 digunakan untuk menetapkan prioritas tentang lalu lintas di mana sumber menyediakan kendali buntu, yaitu., lalu lintas yang " mengundurkan diri" sebagai jawaban atas buntu, seperti TCP lalu lintas. Nilai 8 melalui/sampai 15 digunakan untuk menetapkan prioritas lalu lintas yang tidak mengundurkan diri sebagai jawaban atas buntu, e.g.," real-time" paket dikirim pada suatu tingkat tarip tetap. Karena lalu lintas congestion-controlled, Nilai-Nilai Prioritas yang berikut adalah yang direkomendasikan untuk kategori aplikasi tertentu:
0- lalu lintas tidak ditandai
1- " pengisi" lalu lintas ( e.g., netnews)
2- perpindahan data tanpa kendali ( e.g., email)
3- ( yang dipesan)
4- perpindahan curah yang menghadiri ( e.g., FTP, NFS)
5- ( yang dipesan)
6- lalu lintas interaktip ( e.g., telnet, X)
7- internet mengendalikan lalu lintas ( e.g., menaklukkan protokol, SNMP)
Jika waktu minimum yang diperlukan untuk mereboot cabangnya diketahui(seringkali lebih dari 6 detik). Waktu tsb dapat dikurangi dari periode penantian yang diperlukan sebelum memulai untuk mengalokasi arus label. Tidak ada persyaratan bahwa semua bahkan kebanyakan paket kepunyaan dari aliran, i.e., carry non-zero flow labels. Pengamatan ini ditempatkan disini untuk mengingatkan para perancang protokol dan pelaksana untuk tidak mengasumsikan cara lainnya. Sebagai contoh, akan bersifat tidak bijak untuk mendisain suatu penerus siapa yang penampilannya akan bersifat cukup hanya jika kebanyakan paket merupakan kepunyaan arus, atau untuk mendisain suatu rencana tekanan yang hanya bekerja/lancar pada paket kepunyaan arus.
Karena lalu lintas non-congestion-controlled, Prioritas yang paling rendah menghargai ( 8) harus digunakan untuk yang paket pengirim adalah paling berkeinginan sudah membuang di bawah kondisi-kondisi buntu ( e.g., kesetiaan tinggi lalu lintas video), dan nilai yang paling tinggi ( 15) harus digunakan untuk yang paket pengirim adalah paling sedikit berkeinginan sudah membuang ( e.g., low-fidelas lalu lintas audio). Tidak ada hubungan pemesanan tersiratkan antara prioritas yang congestion-controlled dan yang tidak buntu- prioritas yang dikendalikan.
2.8. Persoalan Upper-Layer Protocol
2.8.1 Upper-Layer Checksums(Lapisan atas Checksums)
Suatu pengangkutan atau lain protokol lapisan atas yang meliputi address dari header IP dalam checksum perhitungan nya harus dimodifikasi untuk menggunakan diatas IPV6, untuk meliputi alamat 128-BIT IPV6
sebagai ganti 32-BIT IPV4 menunjuk. Khususnya, yang berikut ini ilustrasi menunjukkan TCP dan UDP " pseudo-header" untuk IPV6:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Alamat Sumber +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Alamat Tujuan +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Panjangnya Muatan penghasil untung |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nol | Header Berikutnya |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Header Yang berikutnya menghargai pseudo-header mengidentifikasi protokol lapisan atas ( e.g., 6 untuk TCP, atau 17 untuk UDP). Itu akan berbeda dengan Header Yang berikutnya menghargai IPV6 header jika di sana adalah header perluasan antara IPV6 header dan yang bagian atas- header lapisan.
o Panjangnya Muatan penghasil untung menggunakan pseudo-header adalah panjang paket lapisan atas, mencakup header lapisan atas . Itu akan jadi kurang dari Panjangnya Muatan penghasil untung di dalam IPV6 header ( atau di dalam Jumbo Pilihan Muatan penghasil untung) jika ada header perluasan antara IPV6 header dan header lapisan atas.
o Tidak sama dengan IPV4, kapan UDP paket dimulai oleh suatu IPV6, UDP checksum tidaklah opsional. Itu adalah, kapan saja permulaan suatu UDP paket, suatu IPV6 harus menghitung suatu UDP checksum diatas paket dan pseudo-header, dan, jika itu perhitungan menghasilkan suatu hasil nol, [itu] harus diubah ke heksa FFFF untuk penempatan didalam UDP header . IPV6 penerima harus barang buangan UDP paket yang berisi suatu nol checksum, dan perlu membukukan kesalahan.
IPV6 versi ICMP [ RFC-1885] meliputi di atas pseudo-header dalam checksum perhitungan nya ; ini adalah suatu perubahan dari IPV4 versi tentang ICMP, yang tidak meliputi suatu pseudo-header dalam checksum nya . Alasan untuk perubahan adalah untuk melindungi ICMP dari misdelivery atau korupsi bidang IPV6 header yang di atasnya itu semua tergantung, yang mana, tidak sama dengan IPV4, tidaklah dicakup oleh suatu internet-layer checksum. Bidang Header Yang berikutnya didalam pseudo-header untuk ICMP berisi menghargai 58, yang mengidentifikasi IPV6 versi ICMP [itu].
2.8.2 Maximum Packet Lifetime
Tidak sama dengan IPV4, IPV6 node tidaklah diperlukan untuk menyelenggarakan paket maksimum seumur hidup. Itu adalah alasan IPV4 " Waktu untuk Tinggal" bidang adalah yang dinamai kembali " Batas Loncatan" didalam IPV6. Dalam praktek, seluruh sedikit, bila ada, IPV4 implementasi menyesuaikan diri kepada kebutuhan yang mereka membatasi paket seumur hidup, maka ini adalah tak satu perubahan pun dalam praktek. Manapun lapisan atas protokol yang bersandar pada internet layer itu ( apakah IPV4 atau IPV6) untuk membatasi paket seumur hidup hendaknya diupgrade untuk menyediakan sendiri mekanisme untuk mendeteksi dan membuang paket usang.
2.8.3 Maximum Upper-Layer Payload Size
Ketika menghitung ukuran muatan penghasil untung yang maksimum yang tersedia untuk lapisan atas data, suatu lapisan atas protokol harus mempertimbangkan ukuran yang lebih besar tentang IPV6 header sehubungan dengan IPV4 header itu. Sebagai contoh, didalam IPV4, TCP'S MSS pilihan dihitung seperti ukuran paket yang maksimum ( sebuah nilai anggapan atau suatu nilai mempelajari sampai Alur MTU Penemuan) kurang 40 komposisi music 8 suara ( 20 komposisi music 8 suara untuk MINIMUM-LENGTH IPV4 header dan 20 komposisi music 8 suara untuk MINIMUM-LENGTH TCP header ).
Ketika menggunakan TCP diatas IPV6, MSS harus dihitung seperti ukuran paket yang maksimum kurang 60 komposisi music 8 suara, sebab MINIMUM-LENGTH IPV6 header ( yaitu., suatu IPV6 header dengan tidak ada header perluasan) adalah 20 komposisi music 8 suara lebih panjang dibanding suatu minimum-length IPV4 header .
Tidak ada komentar:
Posting Komentar