IPV6

Pengembangan IPV4
Tidak mempunyai flagdays / ketergantungan
High performance network
Waktu sama - > efisien untuk bandwitch rendah
Mekanisme transisi interoperabilas antar host
IPV4 & IPV6
Transisi incremental tidak ada kritis
interdependencies

Perubahan IPV4 IPV6

Memperluas kemampuan pengalamatan
Penyederhanaan format header
Meningkatkan support untuk perluasan
dan pilihan
Mengalirkan kemampuan labeling
Pengesahan dan kemampuan privasi
(Authentication and Privacy Capabilities)

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

IPV6 Header Format

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

Perluasan Header IPV6

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

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

Extension Header Order

Jika ada satu / lebih extension header order dianjurkan
header-header itu nampak pada pesan yang berikut :

IPv6 header

Hop-by-Hop Options header

Destination Options header

Routing header

Fragment header

Authentication header Encapsulating Security

Payload header

Destination Options header

upper-layer header

Options
format :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | 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-Typespecific data.

Highest-order two bits

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

Hop-by-Hop Options Header

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:

Hop-by-Hop Options Header

<cont>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |
Next Header | Hdr Ext Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|
|
.
.
.
Options
.
.
.
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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:

Routing Header <cont>

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Next Header | Hdr Ext Len | Routing Type| Segments Left

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
.
.
.
type-specific data
.
.
.
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Routing Header <cont>

Jenis 0 Routing header mempunyai format yang berikut:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type=0| Segments Left | Reserved| Strict/Loose Bit Map

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
Address[1]
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
Address[2]
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
Address[ n
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Jenis 0 Routing header

Next Header

Hdr Ext Len

Routing Type=0

Reserved
Address[1]
Address[2]

Address[n]

Segments Lef

Jenis 0 Routing header <cont>

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.

Fragment Header
Fragment Header digunakan oleh suatu
IPV6 sumber untuk mengirimkan paket
lebih besar daripada memasukan pada
jalur MTU menuju tujuannya

Fragment Header <cont>

Next Header

Reserved

Fragment
Offset

Identification

Res

Fragment Header <cont>

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.

Fragment Header <cont>

Awal, paket tidak terbagi-bagi besar
dikenal sebagai
" paket yang asli", dan itu
dipertimbangkan untuk terdiri dari dua
bagian,
seperti yang digambarkan:
Unfragmentable
Part

Fragmentable Part

Fragment Header <cont>

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.

Fragment Header <cont>

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"

Fragment Header <cont>

paket asli:
Unfragmentab
le Part

First Fragment

Second
Fragment

Last Fragment

fragment packets:
Unfragmentable Part

Fragment Header

First Fragment

o
o
o

Unfragmentable Part

Fragment Header

Second Fragment

Unfragmentable Part

Fragment Header

Last Fragment

Fragment Header <cont>

Masing-Masing paket fragment adalah
terdiri atas:
Unfragmentable Part dari paket yang asli
Isi Fragment Header
Fragment itu sendiri

Rumus Payload Length

suatu rumusan untuk menghitung Payload
Length panjangnya paket asli yang
dikumpulkan kembali adalah:

PL.ORIG= PL.FIRST- FL.FIRST- 8+ ( 8*

FO.LAST)+ FL.LAST

 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.

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

. Masalah Ukuran Paket

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

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
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
Semua paket yang kepunyaan arus yang sama
harus dikirim dengan alamat sumber yang sama,
alamat tujuan, prioritas, dan label arus.

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 congestioncontrolled dan yang tidak buntu- prioritas yang
dikendalikan.

Persoalan Upper-Layer Protocol

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:
* Header Yang berikutnya menghargai pseudo-header mengidentifikasi protokol lapisan atas
( e.g., 6 untuk TCP, atau 17 untuk UDP).
* Panjangnya Muatan penghasil untung menggunakan pseudo-header adalah panjang paket
lapisan atas, mencakup header lapisan atas .
* 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 pseudoheader 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].

 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.

 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 minimumlength IPV4 header.