Network Working Group Bob Thomas Request for Comments: 426 BBN-TENEX NIC: 13011 23 Ocak 1973 Kategoriler: Protokoller, TELNET Referanslar: 36, 318, 333, 435
Yeniden Bağlanma Protokolü
Bir iletişim yolunun bir veya her iki ucunun bir ana bilgisayardan başka bir ana bilgisayara taşınmasının arzu edildiği durumlar vardır. Bu not, yeniden bağlanma yeteneğinin yararlı olduğu çeşitli durumları tanımlar, yeniden bağlanmayı sağlamak için bir mekanizma sunar, mekanizmanın Host-Host veya TELNET protokolüne nasıl eklenebileceğini taslak olarak açıklar ve mekanizmanın protokol hiyerarşisindeki yerini önerir.
1. Bazı Örnekler
A.
TIP kullanıcılarının ağ durumu bilgisi almak, mesaj göndermek, diğer kullanıcılara bağlanmak vb. için kullanabilecekleri bir yürütücü program durumunu ele alalım. TIP'in sınırlı kaynakları nedeniyle yürütücü program büyük olasılıkla TIP üzerinde değil, bunun yerine TIP ile bazı kaynaklarını paylaşmaya istekli bir veya daha fazla büyük ana bilgisayar üzerinde çalışacaktır (bkz. Şekil 1).
TIP kullanıcısı, "@ EXEC" gibi bir komut yazarak yürütücüye erişebilir; TIP daha sonra Host1'in yürütücü portuna ICP yapar. En son ağ haberlerini aldıktan ve belki birkaç mesaj gönderdikten sonra kullanıcı, Host2'ye (genel olarak Host1 ile aynı değildir) giriş yapmaya ve biraz çalışma yapmaya hazır olur. Bu noktada yürütücü programa Host2'yi kullanmaya hazır olduğunu söylemek ve yürütücünün onu Host2'ye devretmesini ister. Bunu yapmak için yürütücü program önce Host2 ile etkileşime girer, ona TIP'ten bir çağrı beklemesini söyler ve ardından TIP'e Host2'ye yeniden bağlanması talimatını verir. Kullanıcı Host2'den çıkış yaptığında, başka bir yerde daha fazla çalışma yapmaya hazırlanmak üzere Host1'deki yürütücüye geri aktarılabilir. Yeniden bağlanma etkinliği TIP kullanıcısı için görünmez olacaktır.
Yeniden Bağlanma
______ | ______
| | | | |
| EXEC |<-------------+------------>| USER |
|______| | / |______|
Host1 V / TIP
______ /
| |<------/
|______|
Host2
Şekil 1
B.
Bir kullanıcının, ağ üzerindeki herhangi bir sunucuya giriş yapmak için aynı adı ve parolayı (ve belki hesabı) kullanabildiği bir senaryo düşünün. Güvenlik ve ekonomi nedenleriyle her adın ve parolanın her sitede saklanması istenmeyen bir durumdur. Adı veya parolası yerel olarak bulunmayan bir Ana Bilgisayarı kullanmak isteyen bir kullanıcı, ona bağlanır ve her zamanki gibi giriş yapmayı dener (bkz. Şekil 2). Ana Bilgisayar, kullanıcıyı tanımadığını fark ederek onu, kullanıcının iddia ettiği kişi olup olmadığını belirleyebilen bir ağ kimlik doğrulama hizmetine devreder. Kullanıcı kimlik doğrulama testini geçerse, hizmet alabilmesi için tekrar Ana Bilgisayara devredilebilir. Buradaki fikir, kullanıcının Ana Bilgisayar ile Kimlik Doğrulayıcı arasında ileri geri aktarılmasının kullanıcı için görünmez olması gerektiğidir.
(a) ______ kimlik doğrulama için ______
| | | | |
| |<-----------+------------->| User |
|______| | / |______|
Host |/
X
/|
_______ / |
| | / v
| |<---
|_______|
Kimlik Doğrulayıcı
(b)
______ ______
| | | |
| |<--\ ^ /-->| User |
|______| \ | / |______|
Host \ | /
------------+--/
| /
|/
|
/|
/ |
/ | kimlik doğrulama
_______ / | tamamlandı
| | /
| |<------
|_______|
Kimlik Doğrulayıcı
Şekil 2
Eğer kullanıcı Ana Bilgisayara güvenmiyor ve parolasını kimlik doğrulayıcıya devretmek yerine okuyabileceğinden endişe ediyorsa, doğrudan kimlik doğrulama hizmetine bağlanabilir. Kimlik doğrulamasından sonra Kimlik Doğrulayıcı onu Ana Bilgisayara devredebilir.
C.
McROSS hava trafik simülasyon sistemi (bkz. 1972 SJCC makalesi) zaten yeniden bağlanmayı desteklemektedir. Devam eden bir simülasyonun, parçaların bilgisayardan bilgisayara taşınmasına izin vererek kendini yeniden yapılandırmasına olanak tanır. Örneğin, Kuzeydoğu'daki hava trafiğinin bir simülasyonunda, New York Enroute hava sahasını simüle eden program parçası Host2'den Host5'e taşınabilir (bkz. Şekil 3). Yeniden yapılandırma sürecinin bir parçası olarak, New York Terminal alanı simülatörü ve Boston Enroute alanı simülatörleri, Host2'deki New York Enroute simülatörü ile olan bağlantılarını keser ve Host5'te ona yeniden bağlanır.
NY Terminal NY Enroute Boston Enroute Boston Terminal
_____ _____ _____ _____
| | / | | \ | | | |
|Host1|<----/--->|Host2|<---\---->|Host3|<----->|Host4|
|_____| \ / |_____| \ / |_____| |_____|
X taşı X
/ \ | / \
| \ V / |
V \ _____ / V
yeniden bağlan \ | | / yeniden bağlan
->|Host5|<-
|_____|
NY Enroute
Şekil 3
2. Bir Yeniden Bağlanma Mekanizması
Burada önerilen mekanizma, mevcut Host-Host protokolüne veya TELNET protokolüne eklenebilir. Mekanizma önce tanımlanır ve ardından her bir protokole uyarlanması ele alınır.
Yeniden bağlanma mekanizması dört komut içerir:
- Yeniden Bağlanma İsteği: RRQ
<path> - Yeniden Bağlanma Tamam: ROK
<path> - Yeniden Bağlanma Hayır: RNO
<path> - Yeniden Bağlanma Yap: RDO
<path><new destination>
burada <path>, <new destination> hedefine yönlendirilecek iletişim yoludur.
H1'in, A–C iletişim yolunun kendi ucunu kendisinden H3 üzerindeki D portuna taşımak istediğini varsayalım (bkz. Şekil 4).
(a) durum (b) istenen durum
H2 H3 H2 H3
___ ___ ___ ___
| | | | | | | |
| C|<-+ |D | | C|<------>|D |
|___| | |___| |___| |___|
|
|
| ___ ___
| | | | |
+->|A | |A |
|___| |___|
H1 H1
Şekil 4
Yeniden bağlanma adımlar halinde ilerler:
H1 yeniden bağlanmayı ayarlar ve H2'ye RRQ gönderir:
H1 -> H2: RRQ (yol A–C)H2 yeniden bağlanmayı kabul eder ve ROK ile onaylar:
H2 -> H1: ROK (yol C–A)H1, H2'ye yeniden bağlanmayı gerçekleştirmesi talimatını verir:
H1 -> H2: RDO (yol A–C) (Ana Bilgisayar H3, Port D)Yollar kesilir ve yeniden kurulur:
- H1, A–C yolunu keser.
- H2, C–A yolunu keser ve C–D yolunu başlatır.
Yeniden bağlanmanın başarılı olabilmesi için H1'in elbette H3'ün iş birliğini ayarlamış olması gerekir. H1'in bunu yapabileceği yollardan biri, B–D yolunu kurmak ve ardından H2 ile yaptığı değiş tokuşa eşzamanlı olarak H3 ile yeniden bağlanma protokolü değiş tokuşuna girmektir (bkz. Şekil 5):
H1 -> H3: RRQ (yol B–D)
H3 -> H1: ROK (yol D–B)
H1 -> H3: RDO (yol B–D) (Ana Bilgisayar H2, Port C)
H2 H3
______ ______
| | | |
| C | | D |
---\-- -/----
\ /--> <--\ /
\- -/--- --- --- --- --- \---/
\ / \ /
X X
/ \ / \
/ \ / \
yeniden bağlan \ / yeniden bağlan
\ ________ /
---|A B|---
| |
|________|
H1
Şekil 5
Taraflardan herhangi biri, yeniden bağlanmayı reddetmek veya iptal etmek için RNO komutunu kullanabilir. H2, H1'in RRQ'suna RNO ile yanıt verebilir; H1 ise ROK'a RDO yerine RNO ile yanıt vererek yeniden bağlanmayı iptal edebilir.
Yeniden bağlanma sırasında aktarım halindeki iletilerin kaybolmamasını sağlamak kolaydır. H1 tarafından ROK iletisinin alınması, H2'den artık başka ileti gelmeyeceği anlamına gelir; benzer şekilde H2 tarafından H1'den RDO alınması, H1'den artık başka ileti gelmeyeceği anlamına gelir.
Yeniden bağlanma mekanizmasının tanımını tamamlamak için, iki "bitişik" varlığın yeniden bağlanmayı başlattığı durumu ele alalım:
(a) durum (b) istenen durum
H1 H4 H1 H4
____ ____ ____ ____
| | | | | | | |
| C| |E | | C|--------|E |
|____| |____| |____| |____|
H2 H3 H2 H3
____ ____ ____ ____
| | | | | | | |
| B|--------|D | | B| |D |
|____| |____| |____| |____|
H2 ve H3 "eşzamanlı" olarak yeniden bağlanmayı ayarlamaya çalışır:
H2 -> H3: RRQ (yol B–D)
H3 -> H2: RRQ (yol D–B)
Böylece H2, H3'ten kendi RRQ'suna yanıt olarak bir ROK veya RNO yerine bir RRQ görür. Bu "yarış" durumu, yeniden bağlanmaların paralel yerine seri olarak ilerlemesi sağlanarak çözülebilir: önce bir varlık (örneğin H2) yeniden bağlanmasını gerçekleştirir, ardından diğeri (H3) yeniden bağlanmasını gerçekleştirir.
Hangisinin önce gideceğine karar vermek için kullanılabilecek birkaç yöntem vardır. Belki de en basiti, soketler ve site adreslerine dayalı bir karar vermektir: 32 bitlik soket numarası ile 8 bitlik site adresinin birleştirilmesiyle oluşturulan 40 bitlik sayı hangisi için daha büyükse, o varlık önce gider. Bu mekanizma kullanıldığında kural şöyledir:
H2, H3'ten kendi RRQ'suna yanıt olarak bir RRQ alırsa (NH2, NH3 sırasıyla H2 ve H3'e karşılık gelen 40 bitlik sayılar olmak üzere):
- Eğer
NH2 > NH3ise, hem H2 hem de H3, H3'ün RRQ'sunu H2'nin RRQ'suna yanıt olarak bir ROK şeklinde yorumlar. - Eğer
NH2 < NH3ise, her ikisi de H3'ün RRQ'sunu H2'nin RRQ'suna yanıt olarak bir RNO şeklinde yorumlar. Bu, reddi "görmezden gelip" tekrar denemenin mantıklı olduğu tek durumdur — elbette bunu yapmadan önce ilk yeniden bağlanmanın tamamlanmasını bekleyerek.
Bir sıralama belirlendikten sonra, yeniden bağlanma herhangi bir çakışma yokmuş gibi ilerler.
Aşağıdaki diyagram, P tarafından başlatılan bir yeniden bağlanma için yasal protokol komut/yanıt değiş tokuş dizilerini tanımlar:
___ ___
| P |---------------| Q |
|___| |___|
____________________
| P --> Q || R R Q |
|_________||_________|
|
+---------+
|
____V_______________________________________
| || | | |
| Q --> P || R O K | R N O ----| R R Q |
| || | | E | |
|_________||_________|_________|___|_________|
| |
+------------+ v
| Evet +----------+ Hayır
| +------------------------| NP > NQ? |------+
| | +----------+ |
__v___v_______________________________ |
| || | | |
| P --> Q || R D O ----| R N O ----| |
| || | E | | E | |
|_________||_________|___|_________|___| |
|
+--------------------------------------------+
|
____v_________________________________
| || | |
| Q --> P || R D O ----| R N O ----|
| || | E | | E |
|_________||_________|___|_________|___|
NP ve NQ, sırasıyla P ve Q için 40 bitlik sayılardır; E, dizinin sonunu belirtir.
3. Yeniden Bağlanma Mekanizmasının Host-Host Protokolüne Eklenmesi
Dört yeniden bağlanma komutu, Host-Host protokolüne aşağıdaki şekilde doğrudan dahil edilebilir:
RRQ <my socket> <your socket>ROK <my socket> <your socket>RNO <my socket> <your socket>RDO <my socket> <your socket> <new host> <new socket>
Bir gönderme bağlantısı için ROK ve RDO komutları, bağlantı üzerinde aktarım halinde hiçbir ileti kalmayana kadar gönderilmemelidir. RDO komutu bir CLS olarak yorumlanacaktır.
Yeniden bağlanma:
H2 H3 H2 H3
___ ___ ___ ___
| | | | | C|--------|D |
|_C_| |_D_| |___| |___|
| |
| | ===>
| ____ | ____
---|A B|--- | |
|____| |____|
H1 H1
şu şekilde gerçekleştirilebilir:
- H1->H2: RRQ A C
- H1->H3: RRQ B D
- H2->H1: ROK C A
- H3->H1: ROK D B
- H1->H2: RDO A C H3 D
- H1->H3: RDO B D H2 C
- H2->H1: CLS C A
- H3->H1: CLS D B
- H2->H3: STR C D size
- H3->H2: RTS D C link
H2'den gelen STR'nin, H1'den gelen RDO'dan önce H3'e ulaşmasının mümkün olduğunu unutmayın. H3, H1'den bir RDO veya RNO alana kadar bu tür bir RFC'yi kuyrukta tutmaya hazır olmalıdır. Başka bir deyişle, yerel bir soket için bir ROK'un iletilmesi, soketin "açık" durumdan "yeniden bağlanma beklemede" durumuna geçmesine neden olur ve "eşleşen" bir RDO veya RNO alınana kadar sonraki RFC'lerin kuyruklanmasına istekli olunduğunu belirtir.
4. TELNET Protokolünde Yeniden Bağlanma
Host-Host protokolünün yeniden bağlanmayı doğrudan destekleyip desteklemediğinden bağımsız olarak, TELNET protokolüne aşağıdaki beş komutun eklenmesiyle yeniden bağlanma mekanizması TELNET'e dahil edilebilir:
- RRQ
- ROK
- RNO
- RDO
<host> <socket> - RWT
<host> <socket>
burada RRQ, ROK, RNO, RDO ve RWT, 128 ile 255 aralığında uygun şekilde seçilmiş karakterlerdir. İlk üç komut, alındıkları bağlantılara atıfta bulundukları için herhangi bir parametre gerektirmez. RDO ve RWT için, <host> 8 bitlik (= 1 TELNET karakteri) bir ana makine adresi ve <socket> belirtilen ana makinede bir TELNET alma soketini tanımlayan 32 bitlik (= 4 TELNET karakteri) bir sayıdır.
Bekleyen bir yeniden bağlanma, RDO veya RWT ile etkinleştirilebilir. Her ikisine verilen yanıt, önce gönderenle olan TELNET bağlantısını kesmek ve ardından belirtilen ana makine ve soketlere TELNET bağlantısını yeniden açmaktır. RDO için bağlantı iki RFC gönderilerek yeniden açılır; RWT için ise iki RFC beklenerek.
RWT komutu, yukarıda tartışılan STR ile CLS (RDO) arasındaki gibi yarış durumlarını önlemek için tanıtılmıştır. Host-Host protokolünde bu yarış, ROK’un iletimi üzerine bir bağlantının "yeniden bağlanma beklemede" durumuna alınmasıyla önlenir. TELNET için yarış, yeniden bağlanmayı başlatan tarafından RWT ve RDO’nun yerinde kullanımıyla önlenebilir. Örneğin aşağıdaki yeniden bağlanma:
H2 H3 H2 H3
+---+ +---+ +---+ M +---+
| |----+ +---->| | | |------->| |
| Y | N | | Q | Z | ==> | Y | N | Z |
| |<-+ | H1 | +---| | | |<-------| |
+---+ | | M +---+ P | | +---+ +---+ +---+
| +--->| |----+ |
| | X | | H1
+------| |<-----+ +---+
+---+ | |
H1 | X |
| |
+---+
şu şekilde gerçekleştirilebilir:
- X->Y: RRQ
- X->Z: RRQ
- Y->X: ROK
- Z->X: ROK
- X->Y: RWT H3 P
- X, Y ile olan bağlantıları kapatır
- Y, X ile olan bağlantıları kapatır
- Y, H3’ten STR ve RTS bekler
- X->Z: RDO H2 N
- X, Z ile olan bağlantıları kapatır
- Z, X ile olan bağlantıları kapatır
- Z, H2’ye STR ve RTS gönderir; Y bunları eşleşen RTS ve STR ile yanıtlayarak yeniden bağlanmayı tamamlar
TELNET için yeniden bağlanma mekanizması, Cosell ve Walden tarafından RFC #435’te önerilen komut biçimine uyacak şekilde düzenlenebilir. TELNET’e üç yeni komutun eklenmesini düşünün:
- Yeniden Bağlanma için Hazırlık: RCP
- RFC göndererek Yeniden Bağlanmayı Başlatma: RCS
- RFC bekleyerek Yeniden Bağlanmayı Başlatma: RCW
Bu üç komut ile RFC #435’teki DO, DON'T, WILL, WON'T komutları kullanılarak, daha önce önerilen komutlar şu hale gelir:
- RRQ => DO RCP
- ROK => WILL RCP
- RNO => WON'T RCP
DON'T RCP
yani bir RCP’yi iptal etmek için kullanılır. - RDO
<host> <socket>=> DO RCS<host> <socket> - RWT
<host> <socket>=> DO RCW<host> <socket>
RFC #435’in belirttiği gibi, bu yapının güzel yanı, yeniden bağlanmayı uygulamayı seçmeyen bir ana makinenin RCP’nin ne anlama geldiğini bilmek zorunda bile olmamasıdır. DO RCP’ye yanıt olarak yapması gereken tek şey WON'T RCP iletmektir.
5. Öneri
Yeniden bağlanmanın temel bir kavram olduğunu ve protokol hiyerarşisi içindeki doğru yerinin, tüm üst seviye protokollerde kullanılabilir olacağı Host-Host düzeyi olduğunu düşünüyorum. Zorluk şudur ki, bunu oraya yerleştirmek elbette NCP’nin yeniden yazılmasını gerektirecektir. NCP değişiklikleri yapma konusundaki isteksizlik, büyük olasılıkla bu öneriye olan ilgiyi ortadan kaldırmaya yeterli olacaktır.
Bu nedenle, pragmatik nedenlerle, yeniden bağlanma mekanizmasının RFC #435 ruhuna uygun bir "seçenek" olarak TELNET’e dahil edilmesini öneriyorum. Bu, Bölüm 4’te tanımlandığı gibi TELNET protokolüne RCP, RCS ve RCW komutlarının eklenmesiyle gerçekleştirilebilir. Kullanıcı ve sunucu TELNET programlarının bu yeni komutları işleyecek şekilde değiştirilmesi kolay olmalıdır. Yeniden bağlanma seçeneği TELNET protokolünün bir parçası haline getirilirse, TENEX ana makineleri bunu destekleyecektir. Ayrıca, TIP ekibindeki kişiler (Walden ve Cosell) yeniden bağlanma mekanizmasını beğendiklerini ve TELNET protokolünün bir parçası olarak kabul edilmesi halinde, prensipte TIP’ler için bunu uygulamayı kabul ettiklerini söylemişlerdir.
Yeniden bağlanmanın Host-Host düzeyi yerine TELNET düzeyine eklenmesi, kabul etmek gerekir ki bir uzlaşmadır. Ancak bununla birlikte, Bölüm 1’deki Örnek A ve B’de tanımlanan türden etkinlikler mümkün olacaktır.
6. Ek Açıklamalar
A.
Yeniden bağlanma yeni bir kavram değildir. Host-Host protokolü için erken bir öneri (RFC #36), yeniden bağlanmayı desteklemek için olanaklar içermekteydi. RFC #36’daki yeniden bağlanma mekanizması, varlıkların bağlantılar aracılığıyla "papatya zinciri" şeklinde birbirine bağlandığı bir yapı varsayar:
__ __ __ __ __
___| |____| |____| |____| |____| |___
|__| |__| |__| |__| |__|
ve bir veya daha fazla varlığın zincirden nasıl ayrılabileceğini belirtir. Yukarıda önerildiği gibi (Şekil 5), bu notta önerilen mekanizma bu tür bir yeniden bağlanmayı desteklemektedir.
B.
Uygulamada, bitişik varlıklar tarafından eşzamanlı olarak yeniden bağlanma başlatılmasının görece nadir olması beklenir.
C.
RFC #36’da, zincirde bitişik olan varlıkların eşzamanlı yeniden bağlanma girişimlerini ele almak için benimsenen yaklaşım, yeniden bağlanmayı tek ve dikkatle koordine edilmiş küresel bir yeniden bağlanma olarak gerçekleştirmektir. Yukarıda önerilen yerel olarak koordine edilmiş yeniden bağlanmalar dizisinin tercih edilir olduğunu düşünüyorum. N bitişik varlık eşzamanlı olarak yeniden bağlanmaya çalıştığında, RFC #36’da özetlenen tek ve küresel olarak koordine edilmiş yeniden bağlanma yaklaşık ~N² kontrol iletisi gerektirirken, sıralı yerel olarak koordine edilmiş yeniden bağlanma ~N gerektirir.
D.
Güvenlik hakkında birkaç söz yerinde olacaktır. Belirli bir yeniden bağlanma isteğini kabul etme ya da reddetme kararının, bağlantıyı kullanan varlığın (bir terminaldeki kişi veya bir süreç) sorumluluğu olduğu açık olmalıdır. Birçok durumda varlık bu sorumluluğu NCP’sine veya TELNET’ine devretmeyi seçebilir (örneğin, Bölüm 1, Örnek A). Ancak bir Ana Makinenin yeniden bağlanma mekanizmasına sağladığı arayüz, yerel varlıkların uzaktan başlatılan yeniden bağlanma isteklerine verilen yanıt üzerinde denetim kullanabilmelerine olanak tanıyan araçlar içermelidir. Örneğin, bir kullanıcı TELNET’i, uzaktan başlatılan yeniden bağlanmalarla ilgili olarak birkaç çalışma modunu destekleyebilir:
- şeffaf: istenen tüm yeniden bağlanmalar kullanıcıya görünmez bir şekilde gerçekleştirilir;
- görünür: istenen tüm yeniden bağlanmalar gerçekleştirilir ve her yeniden bağlanma gerçekleştiğinde kullanıcı bilgilendirilir;
- onay: kullanıcı her yeniden bağlanma isteğinden haberdar edilir ve bunu kabul edebilir veya reddedebilir;
- reddetme: istenen tüm yeniden bağlanmalar reddedilir.
E.
Yeniden bağlanma, Bressler, Murphy ve Walden tarafından RFC #333’te önerilen Mesaj Anahtarlamalı Protokol (MSP) içinde neredeyse önemsiz bir şekilde gerçekleştirilebilir (MSP içinde "yeniden bağlanma" muhtemelen doğru terim değildir). Örneğin, bu MSP ile aşağıdaki kuralların kullanılması (RFC #333 terminolojisiyle ifade edilmiştir) yeniden bağlanmayı destekler:
- bir yeniden bağlanma devam etmediği sürece, buluşma gönderen tarafta gerçekleşir;
- bir iletişim yolunun alan ucu, buluşma yerinin ve portların adları yeni alıcıya iletilerek taşınabilir;
- kaynağı buluşma yerinden farklı olan bir OUT iletisinin alınması, gönderen ucun taşındığını gösterir; kaynak yer, sonraki IN iletileri için buluşma yeri olarak kullanılmalıdır;
- bir iletişim yolunun gönderen ucu, port adlarının yeni gönderene iletilmesiyle taşınabilir; taşımayı tamamlamak için yeni gönderen, ilk OUT iletisi için önceki gönderenin yerini buluşma yeri olarak, sonraki OUT iletileri için ise kendi yerini buluşma yeri olarak kullanır.
Bu yordam ne kadar basit ve çekici görünse de, MSP mevcut Host-Host protokolünün yerine ya da alternatifi olarak uygulanacak olsaydı, bunun pratikte kullanılacağından şüpheliyim. Bunun nedeni, portların Ana Makineden Ana Makineye aktarılabilmesi yeteneğinin, tahsisatın yönetilmesi için Ana Makineler arasında işbirliği gerektirerek port adı tahsisini (gereksiz yere) karmaşıklaştırmasıdır (örneğin, bir Ana Makine yerel bir süreç tarafından kullanılmak üzere bir port adını güvenle tahsis edebilmeden önce, portun yalnızca yerel olarak kullanılmadığından değil, aynı zamanda ağın herhangi bir yerindeki bir süreç tarafından da kullanılmadığından emin olmalıdır). Ana Makineler arasında portların aktarımını desteklemek için gereken bu işbirliğinin pratikte güvenilir biçimde sağlanması muhtemelen mümkün değildir. Bu nedenle, RFC #333’te tanımlanan türde port aktarımı Host-Host protokolü düzeyinde desteklenmemelidir. Bu sebeple, bir MSP içinde "yeniden bağlanmanın" bu notta önerilen mekanizma gibi bir yöntemle ele alınmasının en iyi yaklaşım olduğunu düşünüyorum.
[Bu RFC, çevrimiçi RFC arşivlerine girmek üzere makine tarafından okunabilir biçime Anthony Anderberg tarafından 4/99 tarihinde dönüştürülmüştür]