本文所提出的RSIPH修改了RSIP及其參數設定，但是，RSIPH卻也繼承了5.2節 所描述的RSIP的混亂現象。在這一個章節裡，本文針對每一個混亂現象提出能避 免或減少其影響的解決方法。以RSIPH為基礎的RG必須為達到網路位址轉換的目 的而儲存Client ID、Bind ID、Address、Port、Lease Time…等參數的值，而為了解 決使用RSIPH時所產生的混亂現象，本文建議在RG裡額外儲存其他必要資訊，並 且提出使用一個埠號範圍（port realm）來支援部分混亂現象的解決，port realm可 以是一個堆疊或佇列結構，內容存放的是已經被使用過且已被釋出的埠號。針對 RSIPH混亂現象，本文分別提出解決方案如下：
Complication 1：Unnecessary TCP TIME_WAIT 解決方案：
為了解決這個問題，所有IP位址與埠號組合（tuple）的狀態，都必須被記錄下 來，包括：最近被釋放（recently de-allocated）的IP與埠號組合。其中，被標註為 RECENTLY_DEALLOCATED的IP與埠號組合必須被持續作記超過兩分鐘後才能 真正被釋放，因為在一般實作上，TIME_WAIT 的最長時限為兩分鐘（RFC793：
2MSL）。除了保留IP與埠號組合的狀態外，為提高新需求取得埠號的效率，凡是 被釋出的埠號必須被置放在本文所提出的port realm裡，當新的網路位址轉換需求 發生時，RG產生一個新的IP與埠號組合，這個組合涵蓋RG所持有的唯一IP位址以 及取自port realm的埠號，萬一port realm是空的，RG就必須隨機產生一個新的埠號 並查核該新的埠號是否已被使用中，也就是說，RG必須產生一個沒有被使用中的 埠號，而這些動作顯然較使用port realm更缺乏效率。
Complication 2：ICMP State in RSIP Gateway 針對問題1的解決方案：
為了區別使用相同IP位址的ICMP requests/responses，ICMP identifier的值就必 須被記錄下 來，在 網 際網路的一 般實作 上 ，ICMP訊息裡的ICMP identifier與 sequence number可視傳送方的需要自行設定其值[60]。因此，解決方法就是將ICMP identifier的值設為RG給予的埠號值，因為對每一個連線需求來說，埠號是唯一的，
所以，根據埠號設定的ICMP identifier也是唯一的，就能夠據以分辨不同的ICMP requests/responses，而ICMP訊息封包裡的sequence number就可以忽略不計。
針對問題2的解決方案：
本文建議在解決這個問題時，由RG檢查IP標頭裡的IP位址以及ICMP訊息封包
Complication 3：Fragmentation and IP Identification Field Collision 解決方案：
為了解決這個衝突問題，作為fragmentation識別用的IP identifier就必須被記錄 下來，本文並建議將IP identifier的值設為RG所給定的埠號值，因為埠號是唯一的，
所以，IP identifier也會是唯一的，就能避免不同的連線封包在進行fragmentation時，
卻誤用相同IP identifier的衝突情形發生。
Complication 4：Application Servers on RSAP-IP Hosts 針對問題1的解決方案：
一般而言，發生在HAN裡的應用絕大部分是屬於遠端操作與管理，MIA並不 需要提供固定的對外服務，縱使部分MIA有意使用well-known port而自成對外公開 的伺服器，基於安全考量，本文強烈建議以RG作為橋樑，而不要讓外部主機能直 接對MIA進行存取，換句話說，由MIA使用well-known port來作為伺服器是不能被 允許的，所以，在本文所提的HAN架構中，這個問題是不會存在的。
針對問題2的解決方案：
從實際使用的觀點看來，HAN裡的MIA是被內部或外部使用者操作或管理著 的，因此，能否使用有異亦的識別方式來辨認MIA是相當關鍵的議題，而有意義 的識別應該是像設備名稱（device name）或設備識別碼（device ID）…之類容易 記憶的名稱，而不是單純的IP位址，基於這樣的設計理念，能夠進行重新導向
（redirection），類似於Domain Name Service（DNS）的名稱-設備對應（name-device mapping）機制就是解決這個問題的替代方案，所有有利於辨認MIA的設備屬性都 應該在實作時被設計在對應機制裡。
Complication 5：Determining Locality of Destinations from a RSIP Host 解決方案：
基本上，HAN可以被視為被RG區隔開來的網際網路的子網路，當任意的MIA 被 安 裝 至HAN 時 ， 與 MIA 相 關 的 參 數 會 被 紀 錄 在 RG 所 持 有 的 註 冊 資 訊 庫
（registration repository）中，包括由RG所指派的私有IP位址（註4）。而註冊資訊 庫中的參數Address是被用來來儲存每一個MIA的私有IP位址，集合所有Address參 數的值，正好形成內部網路的IP列表，再加上絕大部分的MIA都是屬於固定位置
（fixed-location）的家電用品，所以，這份列表的內容更新狀況應該不會太迅速，
因此，透過RG對該列表的查詢，MIA就能先查清楚封包傳送是屬於HAN區域內互 傳，還是必須使用RSIPH，待取得IP與埠號組合後，再將封包往外傳送。
Complicatiion 6：Implementing RSIP Host Deallocation 解決方案：
在HAN裡，RG是唯一具備公開IP位址的設備，而所有的MIA在對外連線時都 必須共同分享這個唯一的IP位址，僅以不同的埠號以示區別，由此可知，埠號是很 珍貴的，因此，有效的埠號分配機制是重要的。因為HAN裡的應用大多是屬於即 時性，且生命週期較短，所以，本文才提出port realm來記錄已被釋放的埠號，並 藉以有效提升埠號分配的效率，同時，將打算釋出的埠號放到port realm的作法，
其實就是一種有效的de-allocation機制，所以，也就不需要特別的dynamic port deallocation mechanism。此外，因為port realm的使用已經包含埠號釋出的功能，一 般為了避免因埠號不足而必須額外再制訂的其他de-multiplexing fields，在本文所提 的RSIPH裡就不是那麼需要了。
Complication 7：Multi-Party Applications 解決方案：
以資料包為基礎（datagram-based）的網際網路所採用的路由方法是造成RSIPH 無法搭配執行multi-party applications的瓶頸，因為路由器必須分析IP封包標頭來決 定傳送路徑，而在這種路由架構下，IP封包標頭與路由機制密不可分，IP資訊的改 變會直接影響封包傳送的路徑，當然，RSIPH也一定會造成影響。再加上RG不可 能給予打算進行multi-party applications的MIA個別獨立的公開IP位址，所以，只要 是 採 用 資 料 包 的 交 換 技 術 ， 就 不 可 能 在 使 用RSIPH的 情 況 下 運 作multi-party applications。目前看來，比較可行的解決方式就是改用其他的交換技術，於是，本 文建議採用與IP協定無關的交換技術，例如：multi-protocol label switching (MPLS) [61][62]。標籤交換（label switching）技術將IP封包的傳送與標籤交換的路由機制 分開來，標籤交換是將短而固定長度的標籤加在封包標頭之前，之後透過標籤之 間的交換取得封包傳送應循的路徑，而毋須分析IP標頭，因此，在標籤交換技術還 沒開始傳送封包之前，已經能在multi-party application的來源端與目的端間建立確 定的封包傳送路徑，而封包在傳送時，標籤的交換與使用是不變的。雖然標籤交 換技術看似能解決這個問題，但是是否所有HAN裡的應用都能正常搭配標籤交換 技術卻是另一個值得探討的議題。