IPV6
IPV6
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
dalam
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
jumlah yang lebih besar untuk pengalamatan nodes, dan autoconfiguration 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.
cara
pilihan
header
IP disandikan
mempertimbangkan
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
Flow Label
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Payload Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
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-ByHop .
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
| Next Header =
TCP
| Routing header
| Next Header =
| Next Header =
Routing
TCP
| header + data
| 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.
10
11
12
Option Data
13
14
paket. Hop-By-Hop header Pilihan dikenali oleh suatu Nilai header berikutnya
Nol pada header IPV6, dan mempunyai format yang berikut:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header berikutnya
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . .
|
Options / pilihan
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header Berikutnya
Gunakan
nilai-nilai
yang
sama
sebagai
field
IPV4
Pilihan
Sebagai tambahan terhadap Pad1 Dan Pad n Pilihan menetapkan bagian 4.2, hopby-hop pilihan yang berikut digambarkan:
Jumbo Payload option ( Kebutuhan Kelurusan: 4N+ 2)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
194
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 yangdikunjungi" 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
16
type-specific data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header berikutnya
8-bit bilangan bulat Positif. Panjangnya Routing header dalam 8octet unit, belum termasuk 8 octets pertama.
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
17
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
Reserved
Address[1]
Address[2]
Routing Type=0
Segments Lef
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
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
18
19
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
Destination Address = I2
Segments Left = 2
Address[1] = I1
20
Address[2] = I3
Address[3] = D
As the packet travels from I2 to I3:
Source Address = S
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
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
Identification
Reserved
Fragment Offset
Res
21
Next Header 8-bit selector. Identifies the initial header type of the Fragmentable
Part of the original
Fragment Offset
Res
M flag
Identification
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
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-
22
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
Second
Part
Fragment
Fragment
Last Fragment
fragment packets:
Unfragmentable Part
Fragment Header
First Fragment
Unfragmentable Part
o
Fragment Header
Second Fragment
23
o
Unfragmentable Part
Fragment Header
Last Fragment
Fragmentable Part
24
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
25
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
26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 highestorder 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
27
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 [ RFC1191], 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
28
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
29
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
30
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
31
Nilai-Nilai
Prioritas
yang
berikut
adalah
yang
32
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
Alamat Sumber
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Alamat Tujuan
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
nol
Header Berikutnya
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
33
o Header
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 atasheader lapisan.
o Panjangnya Muatan penghasil untung menggunakan pseudo-header
adalah panjang paket lapisan atas, mencakup header
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
34
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 MINIMUMLENGTH IPV6 header