Pengertian

IPV6 adalah suatu versi IP baru yang mana dirancang untuk;menjadi suatu langkah
evolusiner dari 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 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.
Pengembangan IPV6
- Perubahan dari IPV4 ke IPV6 terutama pada:
o Memperluas Kemampuan Pengalamatan
o Penyederhanaan Format Header
o Meningkatkan support untuk perluasan dan pilihan
o Mengalirkan Kemampuan Labeling
o Pengesahan Dan Kemampuan Privasi.

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.
3. IPv6 Header Format

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Prio. | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.
Header Pilihan Loncatan, yang membawa informasi yang harus diuji dan
diproses oleh tiap-tiap nodes sepanjang suatu alur penyerahan paket, termasuk sumber
dan nodes tujuan. Hop-By-Hop options header,pada saat pelaksanaan harus dengan
seketika mengikuti IPV6 header. 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

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.

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.
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).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. 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
Jika, sedang memproses menerima sebuah paket, suatu node menemukan routing
header dengan nilai yang tidak dikenali dari suatu routing type, perilaku yang
diperlukan tentang nodes 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, nodes 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]

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.
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:

4.5 Fragment Header

Fragment Header digunakan oleh suatu IPV6 sumber untuk mengirimkan paket lebih
besar daripada memasukan pada jalur MTU menuju tujuannya, dan mempunyai
format yang berikut:

Next Header Reserved Fragment Offset Res M

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.

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 First Fragment Second Last Fragment

Part 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:

1. Unfragmentable Part dari paket yang asli

2. Isi Fragment Header
3. Fragment itu sendiri

Unfragmentable Part Fragmentable Part

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 paket yang dikumpulkan kembali dihitung
dari panjang bagian yang tidak bisa dibagi-bagi lagi. Sebagai contoh, suatu rumusan
untuk menghitung panjangnya muatan penghasil untung 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.Header
Fragmen tidak terdapat di bagian akhir, paket.dikumpulkan kembali.
Kesalahan yang berikut Kondisi-Kondisi boleh ada 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
Panjangnya 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.
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.

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 IPV4 Bidang Protokol [ RFC-
1700 et seq.].
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 untuk Alamat Sumber paket, kemudian informasi
mungkin yang disandikan baik sebagai suatu header terpisah atau sebagai
suatu pilihan .
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).

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.
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 dapat memperoleh suatu Identifikasi untuk
menggunakan menghasilkan IPV4 fragmen.

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]. 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
 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.
Header yang atas 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]. Penerus
boleh kemudian memilih untuk " ingat" hasil itu semua memproses langkah-langkah
dan tempat yang menyembunyikan informasi, menggunakan alamat sumber sebagai
kunci tempat menyembunyikan .
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.
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.
8. Persoalan Upper-Layer Protocol

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:

o Header Yang berikutnya menghargai pseudo-header mengidentifikasi

protokol lapisan atas ( e.g., 6 untuk TCP, atau 17 untuk UDP).
o Panjangnya Muatan penghasil untung menggunakan pseudo-header adalah
panjang paket lapisan atas, mencakup header lapisan atas .
o Tidak sama dengan IPV4, kapan UDP paket dimulai oleh suatu IPV6, UDP
checksum tidaklah opsional.

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].

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.

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.
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.