Jaringan Kelompok Kerja C.

Perkins
Request for Comment: 2003 BM
Kategori: Standar Lacak Oktober 1996


Enkapsulasi P dalam P

Status Memo ini

Dokumen ini menetapkan standar protokol nternet jalur untuk
Komunitas nternet, dan permintaan diskusi dan saran untuk
perbaikan. Silakan merujuk ke edisi terbaru dari nternet "
Protokol Resmi Standar "(STD 1) untuk negara standardisasi
dan status protokol ini. Distribusi memo ini tidak terbatas.

Abstrak

Dokumen ini menetapkan metode yang datagram P dapat
dienkapsulasi (dibawa sebagai payload) dalam sebuah datagram P.
Enkapsulasi adalah disarankan sebagai sarana untuk mengubah normal P routing yang
untuk datagrams, dengan memberikan mereka ke tujuan menengah yang
akan tidak dipilih oleh (bagian jaringan dari) P
Alamat Tujuan lapangan di header P asli. Enkapsulasi
dapat melayani berbagai tujuan, seperti pengiriman datagram ke
ponsel node menggunakan Mobile P.

1. Pengantar

Dokumen ini menetapkan metode yang datagram P dapat
dienkapsulasi (dibawa sebagai payload) dalam sebuah datagram P.
Enkapsulasi adalah disarankan sebagai sarana untuk mengubah normal P routing yang
untuk datagrams, dengan memberikan mereka ke tujuan menengah yang
akan tidak dipilih berdasarkan (bagian jaringan dari) P
Alamat Tujuan lapangan di header P asli. Setelah
dienkapsulasi datagram tiba di node tujuan menengah,
itu decapsulated, menghasilkan P datagram asli, yang kemudian
dikirimkan ke tujuan yang ditunjukkan oleh Tujuan asli
Alamat lapangan. ni menggunakan enkapsulasi dan dekapsulasi dari
datagram sering disebut sebagai "tunneling" datagram, dan
yang encapsulator dan decapsulator kemudian dianggap sebagai
"Endpoint" terowongan.

Dalam kasus tunneling yang paling umum yang telah kita

sumber ---> encapsulator --------> decapsulator ---> tujuan

dengan sumber, encapsulator, decapsulator, dan tujuan yang
node yang terpisah. Simpul encapsulator dianggap sebagai entri "



Standar Perkins Jalur [Halaman 1]

RFC 2003 P-dalam-P Oktober 1996


titik "dari terowongan, dan simpul decapsulator dianggap sebagai
"Keluar jalur" dari terowongan. Ada secara umum dapat beberapa
sumber-tujuan pasangan menggunakan terowongan yang sama antara
encapsulator dan decapsulator.

2. Motivasi

Kelompok kerja Mobile P telah ditentukan penggunaan enkapsulasi sebagai
cara untuk menyampaikan datagram dari "jaringan rumah" node mobile ke
agen yang dapat memberikan datagram secara lokal dengan cara konvensional ke
mobile node di lokasi saat ini jauh dari rumah [8]. Penggunaan
enkapsulasi juga dapat diinginkan kapanpun sumber (atau
intermediate router) dari sebuah datagram P harus mempengaruhi rute dengan
mana datagram akan dikirim ke tujuan akhirnya.
Kemungkinan aplikasi lain dari enkapsulasi termasuk multicasting,
preferensial penagihan, pilihan rute dengan keamanan yang dipilih
atribut, dan routing kebijakan umum.

Hal ini umumnya benar bahwa enkapsulasi dan sumber longgar P
routing pilihan [10] dapat digunakan dalam cara yang sama untuk mempengaruhi routing
dari sebuah datagram, tetapi ada beberapa alasan teknis untuk memilih
enkapsulasi:

- Ada masalah keamanan yang belum terpecahkan terkait dengan penggunaan
sumber P routing pilihan.

- Router nternet saat ini menunjukkan masalah kinerja ketika
forwarding datagram yang berisi opsi P, termasuk P
sumber routing pilihan.

- Banyak internet node proses saat ini sumber P routing pilihan
tidak benar.

- Firewall dapat mengecualikan sumber P datagrams dialihkan.

- Penyisipan pilihan rute P sumber dapat mempersulit
pengolahan informasi otentikasi dengan sumber dan / atau
tujuan datagram, tergantung pada bagaimana otentikasi
ditentukan untuk dilakukan.

- Hal ini dianggap tidak sopan untuk router intermediate untuk membuat
modifikasi untuk datagram yang tidak mereka berasal.

Keuntungan teknis ini harus ditimbang terhadap kerugian
yang ditimbulkan oleh penggunaan enkapsulasi:

- Datagrams Encapsulated biasanya lebih besar dari sumber routed
datagrams.



Perkins Standar Lacak [Page 2]

RFC 2003 P-dalam-P Oktober 1996


- Enkapsulasi tidak dapat digunakan kecuali diketahui terlebih dahulu bahwa
node pada titik keluar terowongan dapat decapsulate datagram.

Karena sebagian besar node internet hari ini tidak melakukan dengan baik ketika
Pilihan sumber P longgar rute yang digunakan, teknis kedua
Kerugian dari enkapsulasi ini tidak seserius mungkin tampak pada
pertama.

3. P di P Encapsulation

Untuk merangkum datagram P menggunakan P di enkapsulasi P, outer
P header [10] terpasang sebelum header P datagram yang ada,
sebagai berikut:

+---------------------------+
| |
| P header Luar |
| |
+---------------------------+ +-------------------- -------+
| | | |
| P header | | P header |
| | | |
+---------------------------+ ====> +--------------- ------------+
| | | |
| | | |
| Payload P | | Muatan P |
| | | |
| | | |
+---------------------------+ +-------------------- -------+

Header luar Alamat P Sumber dan Alamat Tujuan mengidentifikasi
yang "endpoint" terowongan. Header dalam P Alamat Sumber
dan Alamat Tujuan mengidentifikasi pengirim asli dan penerima
dari datagram, masing-masing. Header P batin tidak diubah oleh
yang encapsulator, kecuali untuk pengurangan TTL seperti yang tercantum di bawah ini,
dan
tetap tidak berubah selama pengiriman ke titik keluar terowongan. Tidak ada
perubahan opsi P di header bagian dalam terjadi selama pengiriman
yang dikemas datagram melalui terowongan. Jika perlu, lainnya
header protokol seperti P Authentication header [1] dapat
disisipkan antara header P luar dan dalam header P. Catatan
bahwa opsi keamanan dari header P dalam MUNGKN mempengaruhi
pilihan opsi keamanan untuk header (luar) P encapsulating.









Standar Perkins Melacak [Halaman 3]

RFC 2003 P-dalam-P Oktober 1996


3.1. P header Bidang dan Penanganan

Field dalam header P luar yang ditetapkan oleh encapsulator sebagai
berikut:

Versi

4

HL

Header Length internet (HL) adalah panjang dari P luar
Header diukur dalam 32-bit kata-kata [10].

KL

Jenis Layanan (KL) disalin dari header P batin.

Jumlah Panjang

Jumlah Length mengukur panjang keseluruhan dienkapsulasi
P datagram, termasuk header P luar, P batin
header, dan payload.

dentifikasi, Flags, Fragment Offset

Ketiga bidang ini ditetapkan sebagai ditetapkan dalam [10]. Namun, jika
"Jangan Fragmen" bit diatur dalam header P batin, itu HARUS
diatur dalam header P luar, jika "Jangan Fragmen" bit
tidak diatur dalam header P batin, MUNGKN ditetapkan di P luar
header, seperti yang dijelaskan dalam Bagian 5.1.

Time to Live

Para Time To Live (TTL) lapangan di header P luar diatur ke
sesuai untuk pengiriman datagram dienkapsulasi ke nilai
titik terowongan keluar.

Protokol

4

Header checksum

Header checksum internet [10] dari header P luar.






Perkins Standar Lacak [Halaman 4]

RFC 2003 P-dalam-P Oktober 1996


Alamat sumber

Alamat P dari encapsulator, yaitu, masuk terowongan
titik.

Alamat Tujuan

Alamat P dari decapsulator, yaitu, pintu keluar terowongan
titik.

Pilihan

Setiap pilihan ini dalam header P batin pada umumnya TDAK
disalin ke header P luar. Namun, pilihan baru khusus
ke jalan terowongan MUNGKN ditambahkan. Secara khusus, apapun yang didukung
jenis opsi keamanan dari header P dalam MUNGKN mempengaruhi
pilihan opsi keamanan untuk header luar. Hal ini tidak
diharapkan bahwa ada sebuah pemetaan satu-ke-satu pilihan tersebut untuk
opsi atau header keamanan yang dipilih untuk terowongan.

Ketika encapsulating datagram, TTL dalam header P batin adalah
decremented oleh satu jika terowongan yang dilakukan sebagai bagian dari
forwarding datagram, jika tidak, header TTL batin tidak
berubah selama enkapsulasi. Jika TTL yang dihasilkan di P batin
header adalah 0, datagram akan dibuang dan CMP Time Exceeded
pesan HARUS dikembalikan ke pengirim. Sebuah encapsulator TDAK HARUS
encapsulate datagram dengan TTL = 0.

TTL dalam header P batin tidak berubah ketika decapsulating.
Jika, setelah dekapsulasi, datagram dalam memiliki TTL = 0,
decapsulator HARUS membuang datagram. Jika, setelah dekapsulasi, yang
decapsulator meneruskan datagram ke salah satu interface jaringan,
itu akan pengurangan TTL sebagai akibat dari melakukan P forwarding normal.
Lihat juga Bagian 4.4.

Encapsulator dapat menggunakan mekanisme P yang ada sesuai untuk
pengiriman payload dienkapsulasi ke titik keluar terowongan.Dalam
tertentu, menggunakan opsi P diperbolehkan, dan penggunaan fragmentasi
diperbolehkan kecuali "Jangan Fragmen" bit diatur dalam P dalam
header. Pembatasan ini diperlukan fragmentasi sehingga node
Jalur mempekerjakan Penemuan MTU [7] dapat memperoleh informasi yang mereka
cari.

3.2. Routing Kegagalan

Routing loop dalam sebuah terowongan sangat berbahaya ketika mereka
menyebabkan datagram tiba lagi di encapsulator tersebut.Misalkan suatu
datagram tiba di router untuk meneruskan, dan router



Standar Perkins Melacak [Halaman 5]

RFC 2003 P-dalam-P Oktober 1996


menentukan bahwa datagram harus dienkapsulasi sebelum lanjut
pengiriman. Lalu:

- Jika Alamat P Sumber dari datagram pertandingan router sendiri
Alamat P pada setiap interface jaringan, router TDAK HARUS
terowongan datagram, melainkan datagram HARUS dibuang.

- Jika Alamat P Sumber dari datagram sesuai dengan alamat P
dari tujuan terowongan (titik keluar terowongan biasanya
dipilih oleh router berdasarkan Alamat Tujuan di
P header datagram yang), router TDAK HARUS terowongan datagram;
sebaliknya, datagram HARUS dibuang.

Lihat juga Bagian 4.4.

4. Pesan CMP dari dalam Tunnel

Setelah dikemas datagram telah dikirim, encapsulator dapat
menerima pesan [9] CMP dari semua router perantara dalam
selain titik keluar terowongan terowongan. Tindakan yang diambil oleh
encapsulator tergantung pada jenis pesan CMP yang diterima.Ketika
pesan yang diterima berisi informasi yang cukup, encapsulator yang MUNGKN
menggunakan pesan masuk untuk membuat pesan CMP yang sama, untuk dikirim
ke pencetus P datagram asli unencapsulated (yang
pengirim asli). Proses ini akan disebut sebagai "menyampaikan" yang
CMP pesan dari terowongan.

Pesan CMP menunjukkan kesalahan dalam memproses suatu datagram termasuk
copy (sebagian) datagram menyebabkan kesalahan.Menyampaikan suatu
Pesan CMP mengharuskan strip encapsulator dari P luar
header dari salinan kembali dari datagram asli. Untuk kasus
di mana pesan CMP yang diterima tidak mengandung cukup data untuk
relay pesan, lihat Bagian 5.

4.1. Tujuan Unreachable (Tipe 3)

Pesan CMP Destination Unreachable akan ditangani oleh encapsulator yang
tergantung pada kolom Kode mereka. Model ini memungkinkan disarankan di sini
terowongan untuk "memperpanjang" jaringan untuk memasukkan non-lokal (misalnya,
ponsel)
node. Jadi, jika tujuan asli di unencapsulated
datagram pada jaringan yang sama seperti encapsulator, yakin
Nilai Destination Unreachable Kode dapat dimodifikasi agar sesuai dengan
Model yang disarankan.








Perkins Standar Lacak [Halaman 6]

RFC 2003 P-dalam-P Oktober 1996


Jaringan Unreachable (Kode 0)

Sebuah pesan CMP Destination Unreachable HARUS dikembalikan
ke pengirim asli. Jika tujuan asli di
datagram unencapsulated berada pada jaringan yang sama dengan
encapsulator, yang baru dihasilkan Destination Unreachable
pesan yang dikirim oleh encapsulator yang MUNGKN memiliki Kode 1 (Host
Unreachable), karena diduga datagram tiba di
jaringan yang benar dan encapsulator sedang mencoba untuk menciptakan
kesan bahwa tujuan asli lokal yang
jaringan bahkan jika tidak. Jika tidak, jika encapsulator yang
mengembalikan pesan Destination Unreachable, kolom Kode HARUS
diatur ke 0 (Unreachable Jaringan).

Host Unreachable (Kode 1)

Encapsulator Para HARUS relay host Unreachable pesan ke
pengirim dari datagram unencapsulated aslinya, jika memungkinkan.

Protokol Unreachable (Kode 2)

Ketika encapsulator yang menerima Protokol CMP Unreachable
pesan, itu HARUS mengirim pesan Tujuan Unreachable dengan
Kode 0 atau 1 (lihat diskusi untuk Kode 0) ke pengirim
yang unencapsulated datagram asli. Karena yang asli
pengirim tidak menggunakan protokol 4 dalam mengirimkan datagram, akan
menjadi tidak berarti untuk kembali ke pengirim Kode 2 itu.

Port Unreachable (Kode 3)

Kode ini tidak boleh diterima oleh encapsulator, karena
header P luar tidak merujuk ke nomor port. ni HARUS
TDAK akan disampaikan ke pengirim asli unencapsulated
datagram.

Datagram Terlalu Besar (Kode 4)

Encapsulator HARUS relay pesan CMP Datagram Terlalu Besar untuk
pengirim dari datagram unencapsulated asli.

Rute Sumber Gagal (Kode 5)

Kode ini HARUS ditangani oleh encapsulator sendiri.
ni TDAK HARUS disampaikan ke pengirim asli
unencapsulated datagram.






Perkins Standar Lacak [Halaman 7]

RFC 2003 P-dalam-P Oktober 1996


4.2. Sumber Quench (Tipe 4)

TDAK SEHARUSNYA encapsulator CMP Sumber padamkan relay pesan ke
pengirim dari datagram unencapsulated asli, melainkan HARUS
mengaktifkan mekanisme kontrol kongesti apapun itu menerapkan untuk membantu
mengurangi kemacetan terdeteksi dalam terowongan.

4.3. Redirect (Tipe 5)

Encapsulator MUNGKN menangani pesan CMP Redirect sendiri. ni
TDAK HARUS tidak relay Redirect ke pengirim asli
unencapsulated datagram.

4.4. Waktu Melebihi (Tipe 11)

CMP Time Exceeded melaporkan pesan (dianggap) routing loop dalam
terowongan itu sendiri. Waktu penerimaan pesan oleh Melebihi
encapsulator HARUS dilaporkan ke pengirim asli
unencapsulated datagram sebagai Unreachable Host (Tipe 3, Kode 1). Tuan rumah
Unreachable adalah lebih baik untuk Unreachable Jaringan; sejak datagram
ditangani oleh encapsulator, dan encapsulator sering
dianggap berada di jaringan yang sama sebagai alamat tujuan di
yang unencapsulated asli datagram, maka datagram dianggap
telah mencapai jaringan yang benar, tapi bukan tujuan yang benar
simpul dalam jaringan itu.

4,5. Parameter Masalah (Tipe 12)

Jika poin Parameter pesan Soal ke lapangan disalin dari
asli unencapsulated datagram, encapsulator yang MUNGKN relay CMP
pesan ke pengirim dari datagram unencapsulated asli;
sebaliknya, jika masalah terjadi dengan pilihan P dimasukkan oleh
encapsulator, maka TDAK HARUS encapsulator relay pesan CMP
ke pengirim asli. Perhatikan bahwa berikut encapsulator
praktek saat ini lazim tidak akan memasukkan opsi P ke
dikemas datagram, kecuali mungkin untuk alasan keamanan.

4.6. Pesan CMP lainnya

Pesan CMP lainnya tidak terkait dengan operasi enkapsulasi
diuraikan dalam spesifikasi protokol ini, dan harus bertindak
oleh encapsulator sebagaimana ditetapkan dalam [9].









Standar Perkins Melacak [Halaman 8]

RFC 2003 P-dalam-P Oktober 1996


5. Terowongan Manajemen

Sayangnya, CMP hanya membutuhkan router P untuk kembali 8 oktet (64
bit) dari datagram selain header P. ni tidak cukup untuk
menyertakan salinan dari header (bagian dalam) dikemas P, sehingga tidak
selalu mungkin bagi encapsulator untuk relay pesan CMP dari
interior sebuah terowongan kembali ke pengirim asli. Namun, dengan
hati-hati mempertahankan "negara lunak" tentang terowongan ke dalam yang
mengirimkan,
encapsulator dapat kembali pesan CMP akurat dengan aslinya
pengirim dalam kebanyakan kasus. Encapsulator Para HARUS mempertahankan
setidaknya
berikut informasi negara yang lembut sekitar terowongan masing-masing:

- MTU terowongan (Bagian 5.1)
- TTL (panjang jalan) dari terowongan
- Reachability dari akhir terowongan

Encapsulator menggunakan pesan CMP yang diterima dari interior
terowongan untuk memperbarui informasi negara lunak untuk terowongan itu.
CMP error yang dapat diterima dari salah satu router sepanjang
interior terowongan meliputi:

- Terlalu Besar Datagram
- Waktu Terlampaui
- Tujuan Unreachable
- Sumber Quench

Ketika datagram berikutnya tiba yang akan singgah terowongan itu,
encapsulator memeriksa keadaan lunak untuk terowongan.Jika datagram
akan melanggar keadaan terowongan (misalnya, TTL dari
baru datagram kurang dari terowongan "lunak negara" TTL) yang
encapsulator mengirimkan pesan kesalahan CMP kembali ke pengirim
asli datagram, tetapi juga merangkum datagram dan ke depan
ke dalam terowongan.

Menggunakan teknik ini, pesan kesalahan CMP yang dikirim oleh
encapsulator tidak akan selalu cocok satu-ke-satu dengan kesalahan
ditemui dalam terowongan, tetapi mereka secara akurat akan mencerminkan
keadaan jaringan.

Terowongan negara yang lembut pada awalnya dikembangkan untuk Alamat P
Enkapsulasi (PAE) spesifikasi [4].

5.1. Terowongan MTU Discovery

Ketika Jangan bit Fragmen diatur oleh originator dan disalin ke
header P luar, MTU yang tepat dari terowongan akan dipelajari
dari CMP Datagram pesan Terlalu Besar (Tipe 3, Kode 4) dilaporkan kepada
encapsulator. Untuk mendukung pengiriman node yang menggunakan Path MTU
Discovery,



Standar Perkins Melacak [Halaman 9]

RFC 2003 P-dalam-P Oktober 1996


semua implementasi encapsulator HARUS dukungan Path MTU Discovery [5,
7] negara yang lembut di dalam terowongan mereka. Dalam aplikasi tertentu,
ada beberapa keuntungan:

- Sebagai manfaat dari Path MTU Discovery dalam terowongan, setiap
fragmentasi yang terjadi karena ukuran
Header enkapsulasi dilakukan hanya sekali setelah enkapsulasi.
Hal ini untuk mencegah fragmentasi beberapa datagram tunggal, yang
meningkatkan efisiensi pengolahan decapsulator dan
router dalam terowongan.

- Jika sumber dari datagram unencapsulated melakukan MTU Jalan
Discovery, maka diinginkan untuk encapsulator untuk mengetahui
MTU terowongan. Setiap datagram CMP Terlalu Besar pesan dari
dalam terowongan dikembalikan ke encapsulator itu, dan seperti dicatat
dalam Bagian 5, tidak selalu mungkin untuk encapsulator untuk
CMP relay pesan ke sumber asli unencapsulated
datagram. Dengan mempertahankan "negara lunak" tentang MTU
terowongan, encapsulator dapat kembali benar CMP Datagram Terlalu Besar
pesan ke pengirim asli dari datagram unencapsulated untuk
Jalur dukungan sendiri MTU Discovery. Dalam hal ini, MTU yang
disampaikan ke pengirim asli oleh encapsulator yang HARUS
menjadi MTU terowongan dikurangi ukuran encapsulating
P header. ni akan menghindari fragmentasi P asli
datagram oleh encapsulator tersebut.

- Jika sumber datagram asli unencapsulated
tidak melakukan Path MTU Discovery, masih diinginkan untuk
encapsulator untuk mengetahui MTU terowongan. Secara khusus, hal ini
jauh lebih baik untuk fragmen datagram asli ketika encapsulating,
daripada membiarkan datagram dikemas menjadi terfragmentasi.
Fragmenting datagram asli dapat dilakukan oleh encapsulator yang
tanpa persyaratan penyangga khusus dan tanpa perlu
tetap reassembly negara dalam decapsulator tersebut.Sebaliknya, jika
datagram dienkapsulasi terfragmentasi, maka decapsulator yang
harus memasang kembali (encapsulated) datagram sebelum
decapsulating itu, negara membutuhkan reassembly dan ruang buffer
dalam decapsulator tersebut.

Jadi, encapsulator biasanya HARUS lakukan Path MTU Discovery,
membutuhkan untuk mengirim semua datagram ke dalam terowongan dengan "Jangan
Fragmen "sedikit diatur dalam header P luar. Namun, ada masalah
dengan pendekatan ini. Ketika pengirim asli set "Jangan
Fragmen "sedikit, pengirim dapat bereaksi dengan cepat untuk setiap CMP kembali
Terlalu Big datagram pesan kesalahan mentransmisi asli
datagram. Di sisi lain, anggaplah bahwa encapsulator menerima
Datagram CMP pesan Terlalu Besar dari dalam terowongan.Dalam yang
kasus, jika pengirim asli dari datagram unencapsulated tidak



Standar Perkins Jalur [Halaman 10]

RFC 2003 P-dalam-P Oktober 1996


mengatur "Jangan Fragmen" sedikit, tidak ada apa-apa masuk akal bahwa
encapsulator dapat lakukan untuk membiarkan pengirim tahu kesalahan.
Encapsulator MUNGKN menyimpan salinan dari datagram yang dikirim setiap kali
mencoba meningkatkan MTU terowongan, dalam rangka memungkinkan untuk fragmen
dan
mengirim ulang datagram jika mendapat respon Datagram Terlalu Besar.
Atau encapsulator yang MUNGKN dikonfigurasi untuk jenis tertentu
datagram tidak mengatur "Jangan Fragmen" sedikit ketika asli
pengirim dari datagram unencapsulated tidak mengatur "Jangan
Fragmen "sedikit.

5.2. Kemacetan

Sebuah encapsulator mungkin menerima indikasi kemacetan dari
terowongan, misalnya, dengan menerima CMP Sumber Quench pesan dari
node dalam terowongan. Selain itu, lapisan link tertentu dan
berbagai protokol tidak berhubungan dengan suite nternet protokol
mungkin memberikan indikasi tersebut dalam bentuk suatu Kemacetan
Berpengalaman [6] bendera. Encapsulator yang HARUS mencerminkan kondisi dari
kemacetan di "negara lunak" untuk terowongan, dan apabila kemudian
forwarding datagram ke dalam terowongan, encapsulator yang HARUS menggunakan
sesuai sarana untuk mengendalikan kemacetan [3]; Namun,
encapsulator TDAK HARUS mengirim pesan CMP Sumber padamkan ke
asli pengirim datagram unencapsulated.

6. Pertimbangan Keamanan

Enkapsulasi P berpotensi mengurangi keamanan nternet,
dan perawatan harus diambil dalam pelaksanaan dan penyebaran P
enkapsulasi. Sebagai contoh, enkapsulasi P membuat sulit bagi
router perbatasan untuk menyaring datagram berdasarkan field header. Dalam
tertentu, nilai-nilai asli dari Alamat Sumber, Tujuan
Alamat, dan Protokol field dalam header P, dan nomor port
digunakan dalam transport header dalam datagram, tidak berlokasi di
posisi mereka yang normal dalam datagram setelah enkapsulasi.
Karena setiap datagram P dapat encapsulated dan melewati sebuah
terowongan, seperti router perbatasan penyaringan perlu hati-hati memeriksa semua
datagrams.

6.1. Pertimbangan router

Router perlu menyadari protokol enkapsulasi P untuk
benar menyaring datagrams masuk. Sangat diharapkan bahwa seperti
penyaringan diintegrasikan dengan otentikasi P [1]. Dimana P
otentikasi digunakan, paket dikemas mungkin akan diizinkan untuk
masukkan sebuah organisasi ketika paket (luar) atau encapsulating
dienkapsulasi (batin) paket yang dikirim oleh otentik, terpercaya
sumber. Encapuslated paket yang berisi tidak ada otentikasi, misalnya
merupakan risiko keamanan yang berpotensi besar.



Perkins Standar Lacak [Halaman 11]

RFC 2003 P-dalam-P Oktober 1996


Datagram P yang dikemas dan dienkripsi [2] juga mungkin menimbulkan
masalah untuk router penyaringan. Dalam kasus ini, router dapat menyaring
datagram hanya jika saham asosiasi keamanan yang digunakan untuk
enkripsi. Untuk memungkinkan ini jenis enkripsi dalam lingkungan di
semua paket yang perlu disaring (atau setidaknya dicatat), sebuah
Mekanisme harus di tempat untuk node penerima untuk aman
berkomunikasi asosiasi keamanan untuk router perbatasan. ni
mungkin, lebih jarang, juga berlaku untuk asosiasi keamanan yang digunakan untuk
keluar datagram.

6.2. Tuan Pertimbangan

Tuan implementasi yang mampu menerima P dienkapsulasi
datagrams HARUS mengakui hanya mereka pas datagram ke dalam satu atau lebih
dari kategori berikut:

- Protokol ini berbahaya: alamat sumber berbasis otentikasi
tidak diperlukan.

- The (luar) encapsulating datagram berasal dari autentik
mengidentifikasi sumber, terpercaya. Keaslian sumber bisa
dibentuk dengan mengandalkan keamanan fisik di samping
konfigurasi router perbatasan, tetapi lebih cenderung datang dari penggunaan
dari header P Authentication [1].

- The (batin) encapuslated datagram mencakup P Authentication
header.

- Para encapsulated (batin) datagram ditujukan ke jaringan
antarmuka milik decapsulator, atau ke node yang
decapsulator telah mengadakan hubungan khusus untuk
memberikan datagrams dienkapsulasi tersebut.

Beberapa atau semua pemeriksaan ini bisa dilakukan di router perbatasan bukan
dari node yang menerima, tetapi lebih baik jika pemeriksaan perbatasan router
digunakan sebagai cadangan, bukannya cek saja.















Perkins Standar Lacak [Halaman 12]

RFC 2003 P-dalam-P Oktober 1996


7. Ucapan Terima Kasih

Bagian dari Bagian 3 dan 5 dari dokumen ini diambil dari bagian
(Ditulis oleh Bill Simpson) dari versi sebelumnya dari Mobile P
Draft internet [8]. Teks asli untuk bagian 6 (Keamanan
Pertimbangan) disumbangkan oleh Bob Smart. de bagus juga
dimasukkan dari RFC 1853 [11], juga ditulis oleh Bill Simpson.
Terima kasih juga kepada Anders Klemets untuk mencari kesalahan dan menyarankan
perbaikan draft. Akhirnya, terima kasih kepada David Johnson untuk
pergi atas rancangan dengan sisir bergigi halus, menemukan kesalahan,
meningkatkan konsistensi, dan membuat banyak perbaikan lainnya dengan
konsep.

Referensi

[1] Atkinson, R., "Otentikasi header P", RFC 1826, Agustus 1995.

[2] Atkinson, R., "P Encapsulating Security Payload", RFC 1827,
Agustus 1995.

[3] Baker, F., Editor, "Persyaratan untuk Router P Versi 4", RFC
1812, Juni 1995.

[4] Gilligan, R., Nordmark, E., dan B. Hinden, "PAE: The SPP
nteroperabilitas dan Mekanisme Transisi ", Work in Progress.

[5] Knowles, S., "Nasihat ESG dari Pengalaman dengan Path MTU
Penemuan ", RFC 1435, Maret 1993.

[6] Mankin, A., dan K. Ramakrishnan, "Gateway Kontrol Kemacetan
Survei ", RFC 1254, Agustus 1991.

[7] Mogul, J., dan S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.

[8] Perkins, C, Editor, "Mobilitas Dukungan P", RFC 2002,
Oktober 1996.

[9] Postel, J., Editor, "nternet Control Message Protocol", STD 5,
RFC 792, September 1981.

[10] Postel, J., Editor, "nternet Protocol", STD 5, RFC 791,
September 1981.

[11] Simpson, W., "P di P Tunneling",, RFC 1853 Oktober 1995.






Standar Perkins Melacak [Halaman 13]

RFC 2003 P-dalam-P Oktober 1996


Alamat Penulis

Pertanyaan tentang memo ini dapat diarahkan untuk:

Charles Perkins
Kamar H3-D34
T. J. Watson Research Center
BM Corporation
30 Saw Mill River Rd.
Hawthorne, NY 10532

Pekerjaan: +1-914-784-7350
Faks: +1-914-784-6205
EMail: perk@watson.ibm.com

Kelompok kerja dapat dihubungi melalui kursi saat ini:

Jim Salomo
Motorola, nc
1301 E. Algonquin Rd.
Schaumburg, L 60196

Pekerjaan: +1-847-576-2753
EMail: solomon@comm.mot.com