異質網路漫遊系統整合平台之設計與實作

全文

(1)國立交通大學資訊工程學系碩士論文. 異質網路漫遊系統整合平台之設計與實作 Design and Implementation of an Integration Platform for Heterogeneous Network Roaming Systems. 研究生: 范榮軒指導教授: 曾建超教授. 中華民國九十四年五月.

(2) 異質網路漫遊系統整合平台之設計與實作研究生：范榮軒. 指導教授：曾建超博士國立交通大學資訊工程學系碩士班. 摘要隨著行動運算技術的普及化，現今市面上多數的可攜式裝置如筆記型電腦、平板電腦、個人數位助理或是智慧型手機等可能皆已具備存取網際網路的能力。不僅如此，這些裝置通常擁有不止一種的網路介面，包括有線的區域網路、無線的區域網路、GPRS，甚至是 PHS 或是 3G。然而我們發現到在硬體逐漸成熟的同時，卻缺乏一套可以整合這些異質性網路的軟體讓使用者能根據目前所在的位置選用適當的網路媒體並且維持切換時原有的連線。在本論文中，我們便設計與實作此異質網路漫遊系統整合平台於裝有微軟視窗作業系統 Windows XP 的可攜式裝置上。此平台提供的功能有收集網路卡的狀態資訊、自動選擇最適當的網路卡、由選定網路卡繞送/擷取往返的封包以及維持行動裝置原有的連線。由於網路介面在選擇上必須考量其連線狀態、網路頻寬、計費標準與使用者偏好等複雜的因素，因此本論文僅專注於網路卡管理與路由等方面的技術探討。為了驗證我們的方法，我們也實作了一個運作於用戶模式下以優先權為考量的切換抉擇演算法軟體模組來為行動裝置自動選擇一張適當的網路卡。首先，為了選擇一張適當的網路卡，切換抉擇模組必須取得網路卡的相關狀態。這些狀態是由連結狀態、訊號強度等的鏈結層資訊與諸如 DHCP 位址、DHCP 閘道、路由表與 ARP 快取表等的網路層資訊所共同組成。其中切換抉擇模組藉由呼叫 IPHLPAPI 函式庫來存取網路層資訊。但是由網路卡所提供的鏈結層資訊則僅提供給 NDIS 驅動程式來使用。因此我們便實作了稱為 NdisProt 的核心驅動程式來收集鏈結層資訊並提供給用戶模式下之應用程式存取的介面。除此之外，為了加速切換，我們在 NdisProt 中也加入了 layer-2 trigger 並且利用 IPHLPAPI 函式庫來攔截 DHCP 事件以減低切換抉擇模組偵測網路卡狀態改變的等待時間。 i.

(3) 其次，我們實作了 Mobile IP 來支援行動裝置切換網路卡時的原有連線維持。在這部分我們所採用的是配置轉交位址模式，如此一來我們便可以視每個網路僅為一個用來存取的網路而不需要網路服務提供者的任何支援。然而，在配置轉交位址模式下，Mobile IP 軟體必須將應用程式所送出的封包在到達指定的網路卡前做封裝的動作，反之它也要將網路卡所收到的封包在傳遞給應用程式前做拆裝的動作。因此，為了從 Windows 的 NDIS 架構中攔截不管是由應用程式所送出或是自網路卡所收到的封包做後續的封裝或拆裝，我們設計了兩個核心驅動程式 NdisFlt 與 IpFlt 於此平台中。此外，由於 Windows XP 在 SP2 之後便不再提供 raw socket 給 Mobile IP 軟體來傳送已封裝/拆裝的封包，Mobile IP 軟體便必須自行做乙太網路訊框的封裝後將該訊框直接送往指定網路卡的迷你連接埠驅動程式。再者，Mobile IP 需要將家位址固定地設定在行動裝置的其中一張網路卡上，而該網路卡在當行動裝置移動時也需要動態地透過 DHCP 取得配置轉交位址。所以整合平台運用了 IP Alias 的技巧將家位址與轉交位址同時地設定在一張網路卡上。不過，在 Windows NDIS 架構中的 Media Sense 功能在網路卡失效時會通知 TCP/IP 協定驅動程式。一旦 TCP/IP 協定驅動程式收到該訊息，它便會移除該失效網路卡上相關的 IP 位址設定。因此為了永遠保持家位址的存在，整合平台插入了一隻中間層驅動程式來避免 TCP/IP 協定驅動程式得知設有家位址之網路卡的連結狀態。最後，整合平台也實作了 IETF 所提出的 UDP 承載 IP 封裝標準讓行動端漫遊於私有網域內。然而有鑑於 UDP 承載 IP 封裝帶來過多的標頭封裝與封包分割，我們提出了一個新穎的 Mobile IP 穿越網路位址轉譯器機制。由效能評估的結果可發現我們的方法將優於原有 IETF 所提出的。. ii.

(4) Design and Implementation of an Integration Platform for Heterogeneous Network Roaming Systems Student: Jung-Hsuan Fan. Advisor: Dr. Chien-Chao Tseng. Department of Computer Science and Information Engineering National Chiao Tung University. Abstract As wireless networks and mobile terminal technologies advance, most mobile devices, such as notebooks, tablet PCs, PDAs, or smart phones, may have more than one network interface, including wired LAN, wireless LAN, GPRS, PHS, and even 3G, and can access Internet with any appropriate interface. However, although the hardware of the mobile devices gradually becomes more and more mature, there is still lack of software that can manage these heterogeneous network interfaces and help users adopt the most suitable media to retain the ongoing sessions when mobile devices change the points of network attachment. In this thesis, we present the design and implementation of a software platform for integrating multiple heterogeneous network interfaces on a mobile device of Microsoft Windows XP. The integration platform provides the functionalities of gathering the statuses of network interfaces, automatically selecting the most appropriate interface, routing/intercepting packets to/from a designated interface and retaining the ongoing sessions for the mobile device. Because interface selection is a complex decision depending on the connectivity, bandwidths and tariffs of the interfaces, and/or sometimes the user preferences, this thesis focuses only on the techniques issues of interface management and routings. For the demonstration purpose, we also implement a priority-based handoff decision software module, which operates in the user space, to select an appropriate interface automatically for the mobile device. First, in order to select an appropriate interface, the handoff decision module needs to obtain the statuses of the network interfaces. The network statuses consists of layer-2 information, such as link status and signal strength, and layer-3 information, such as DHCP address, DHCP gateway, routing table, and ARP cache. The layer-3 information can be accessed by the handoff decision module by calling the IPHLPAPI library. However the layer-2 information provided by network interfaces can only be accessed by the NDIS drivers. Therefore we implement an. iii.

(5) NdisProt kernel driver to collect layer-2 information and provide interfaces for the user level program to acquire the layer-2 information. Furthermore, in order to speedup the handoff process, we also implement layer-2 triggers in NdisProt and hook layer-3 DHCP events with the IPHLPAPI library to reduce the waiting time for the handoff decision module to detect the changes in interface statuses. Second, we also implement Mobile IP to support session continuity when a mobile device switches from one network interface to another. We adopt the co-located care-of address (CoCoA) mode of Mobile IP so that our system can treat each network simply as an access network and does not need any supports from the network providers. However, in Co-CoA mode, the mobile IP software needs to encapsulate packets sent by user programs before routing the packets to a designated interface, and decapsulate packets received from an interface before sending the packets to user programs. Therefore, in order to intercept packets, either sent by a user level program or received from a network interface, from Windows NDIS framework for further encapsulation and decapsulation, we also develop two kernel drivers NdisFlt and IpFlt in the platform. Moreover, because Windows XP after the Service Pack 2 does not provide raw socket for the mobile IP software anymore to send the encapsulated/decapsulated packets, the mobile IP software also needs to perform Ethernet frame encapsulation itself and send the frame directly to the miniport driver of the designated interface. Furthermore, mobile IP needs to bind the home IP address statically to one of the mobile device’s interfaces that may acquire Co-CoAs dynamically as the mobile device moves. Therefore the integration platform applies IP alias technique and binds the home IP address and a Care-of Address simultaneously with an interface card of the mobile device. However the Media Sense function of Windows NDIS will notify the TCP/IP protocol driver when an interface becomes inactive. Upon receiving the notification, the TCP/IP protocol driver will remove the IP address configuration of the inactive interface. In order to retain the home IP permanently, the integration platform also inserts an intermediate driver to prevent TCP/IP protocol driver from knowing the link status of the interface bound with the home IP address. Finally, the integration platform also implements the IETF IP-in-UDP tunnel standard for the mobile nodes to roam under private networks. Nevertheless, because IP-in-UDP tunnel introduces too much header encapsulation and IP fragmentation overhead, we also propose a novel NAT traversal mechanism for mobile IP. The performance results show that our NAT traversal mechanism outperforms the IETF one.. iv.

(6) Acknowledgement 本論文得以順利完成首要感謝我的指導教授－曾建超博士，在過去三年來對於我的耐心指導與多方教誨，尤其是在論文撰寫與口試期間給予不厭其煩的指正與啟發。同時要向我的論文口試委員：蔡文能博士與紀光輝博士致上謝意，感謝他們在百忙中撥冗細心地審查我的論文並提供寶貴的參考意見，使此研究成果表現的臻至完善。還有要謝謝無線網際網路研究室(Wireless Internet Laboratory)的同學俊儀，學弟大鈞、凱程與宜榮在程式設計的部分不吝嗇地給予協助。而對研究室內其他的學長姊與學弟妹也要感謝他/她們在生活中給我的照顧與陪伴，讓我的碩士生涯豐富而充實。除此之外也要特別感謝多年來一直關心我的沛沛、廣慧、教昌、佳靜與子貴等好友，在我碰到困難或遭遇挫折之時給我精神上與實質上的協助，讓我順利地克服一次次的難關。最後由衷地感謝在背後默默支持與鼓勵我的父母，有他們的栽培才有今日我的成就。僅將此成果獻給家人以及所有關心我的師長與親朋好友。. Ode on Intimations of Immortality What though the radiance which was once so bright Be now for ever taken from my sight, Though nothing can bring back the hour Of splendour in the grass, of glory in the flower; We will grieve not, rather find Strength in what remains behind ～ William Wordsworth v.

(7) Contents Abstract in Tradtional Chinese................................................................................................................... i Abstract in English..................................................................................................................................... iii Acknowledgement ........................................................................................................................................v Contents ...................................................................................................................................................... vi Figures ......................................................................................................................................................... ix Tables ......................................................................................................................................................... xii CHAPTER 1. INTRODUCTION ......................................................................................................................1. SECTION 1.1. MOTIVATION ....................................................................................................................1. SECTION 1.2. APPROACH ........................................................................................................................1. SECTION 1.3. SYNOPSIS ..........................................................................................................................2. CHAPTER 2. BACKGROUND MATERIAL.....................................................................................................3. SECTION 2.1. MOBILE IP ........................................................................................................................3. 2.1.1 MECHANISM ...........................................................................................................................4 2.1.2 SIGNALING .............................................................................................................................8 2.1.3 DATA ENCAPSULATION ........................................................................................................14 2.1.4 SPECIFIC PROBLEMS SECTION 2.2. AND SOLUTIONS ..........................................................................16. NAT................................................................................................................................17. 2.2.1 NAT MOTIVATION ...............................................................................................................17 2.2.2 NAT OPERATION .................................................................................................................18 SECTION 2.3. PACKET INTERCEPTING TECHNIQUE ON MICROSOFT WINDOWS ...................................21. 2.3.1 NDIS OVERVIEW .................................................................................................................21 2.3.2 USER-MODE APPROACH .......................................................................................................24 2.3.3 KERNEL-MODE APPROACH ..................................................................................................26 SECTION 2.4. ROUTING MECHANISM UNDER MICROSOFT WINDOWS..................................................29. 2.4.1 DIRECT AND INDIRECT DELIVERY .......................................................................................29 2.4.2 ROUTING TABLE...................................................................................................................30 2.4.3 PHYSICAL ADDRESS RESOLUTION .......................................................................................33 CHAPTER 3. RELATED WORK ..................................................................................................................36. SECTION 3.1. WIRELESS DATA NETWORK INTEGRATION ....................................................................36. 3.1.1 INTERWORKING ARCHITECTURES ........................................................................................36 3.1.2 CURRENTLY IMPLEMENTATIONS .........................................................................................39. vi.

(8) SECTION 3.2. MOBILE IP NAT TRAVERSAL .........................................................................................47. 3.2.1 THE PATENT SOLUTION .......................................................................................................48 3.2.2 THE IETF SOLUTION ............................................................................................................48 CHAPTER 4. RADIO MOBILE IP (RIOMIP).............................................................................................51. SECTION 4.1. OBJECTIVES ....................................................................................................................51. SECTION 4.2. SYSTEM ARCHITECTURE ................................................................................................53. SECTION 4.3. ROAMING SCENARIOS ....................................................................................................54. 4.3.1 LAN-WLAN ROAMING SCENARIO AND MESSAGE FLOW...................................................54 4.3.2 WLAN-GPRS ROAMING SCENARIO AND MESSAGE FLOW .................................................57 SECTION 4.4. SOFTWARE COMPONENTS ..............................................................................................60. 4.4.1 NDISFLT DRIVER ..................................................................................................................61 4.4.2 IPFLT DRIVER .......................................................................................................................62 4.4.3 MOBILE IP SERVICE INTERMEDIATE DRIVER ......................................................................63 4.4.4 NDISPROT PROTOCOL DRIVER .............................................................................................65 4.4.5 RIOMIP MOBILITY MANAGEMENT CLIENT ........................................................................67 CHAPTER 5. ALTERNATIVE TUNNELING FOR MOBILE IP NAT TRAVERSAL .......................................73. SECTION 5.1. OBJECTIVES ....................................................................................................................73. SECTION 5.2. SYSTEM ARCHITECTURE ................................................................................................74. SECTION 5.3. PROTOCOL SKETCH ........................................................................................................75. SECTION 5.4. DETAIL DESIGN ..............................................................................................................76. 5.4.1 DATA STRUCTURE ................................................................................................................76 5.4.2 NETWORK ADDRESS SWAPPING (NAS) FUNCTION .............................................................77 5.4.3 PROTOCOL DESCRIPTION .....................................................................................................79 CHAPTER 6. IMPLEMENTATION ISSUE ....................................................................................................82. SECTION 6.1. IMPLEMENTATION OF RADIO MOBILE IP........................................................................82. 6.1.1 ENVIRONMENT CONFIGURATION .........................................................................................82 6.1.2 SOFTWARE DEVELOPMENT ..................................................................................................84 6.1.3 SOFTWARE DEMONSTRATION ............................................................................................102 SECTION 6.2. IMPLEMENTATION OF ALTERNATIVE TUNNELING .......................................................107. 6.2.1 ENVIRONMENT CONFIGURATION .......................................................................................107 6.2.2 SOFTWARE DEVELOPMENT ................................................................................................110 6.2.3 SOFTWARE DEMONSTRATION ............................................................................................115 CHAPTER 7. DISCUSSION AND REMARK ................................................................................................117. SECTION 7.1. MULTI-INTERFACE INTEGRATION ALTERNATIVES ......................................................117. 7.1.1 HOME IP ADDRESS CONFIGURATION .................................................................................117 vii.

(9) 7.1.2 PACKET ENCAPSULATION ..................................................................................................118 7.1.3 LINK LAYER INFORMATION ...............................................................................................118 SECTION 7.2. PERFORMANCE EVALUATION OF MOBILE IP NAT TRAVERSAL ..................................119. 7.2.1 BANDWIDTH UTILIZATION .................................................................................................119 7.2.2 TCP THROUGHPUT ESTIMATION ........................................................................................121 7.2.3 FAULT TOLERENCE CABILITY ............................................................................................122 CHAPTER 8. CONCLUSION AND FUTURE WORK ...................................................................................123. SECTION 8.1. CONCLUSION ................................................................................................................123. SECTION 8.2. FUTURE WORK .............................................................................................................124. APPENDIX A. REFERENCE ....................................................................................................................125. viii.

(10) Figures FIGURE 2 - 1: HOME NETWORK SCENARIO .....................................................................................................6 FIGURE 2 - 2: FOREIGN NETWORK SCENARIO UNDER FA COA MODE ..........................................................7 FIGURE 2 - 3: FOREIGN NETWORK SCENARIO UNDER CO-LOCATED COA MODE ..........................................8 FIGURE 2 - 4: ICMP ROUTER ADVERTISEMENT FORMAT ..............................................................................9 FIGURE 2 - 5: AGENT ADVERTISEMENT EXTENSION FORMAT .......................................................................9 FIGURE 2 - 6: ICMP ROUTER SOLICITATION FORMAT ...................................................................................9 FIGURE 2 - 7: REGISTRATION REQUEST MESSAGE FORMAT ........................................................................10 FIGURE 2 - 8: REGISTRATION REPLY MESSAGE FORMAT.............................................................................10 FIGURE 2 - 9: AUTHENTICATION EXTENSION FORMAT ................................................................................11 FIGURE 2 - 10: AUTHENTICATION EXTENSION ORDER .................................................................................12 FIGURE 2 - 11: REGISTRATION FLOW ...........................................................................................................13 FIGURE 2 - 12: IP-IN-IP ENCAPSULATION AND HEADER FORMAT ...............................................................14 FIGURE 2 - 13: MINIMAL ENCAPSULATION AND HEADER FORMAT .............................................................15 FIGURE 2 - 14: GRE ENCAPSULATION AND HEADER FORMAT ....................................................................15 FIGURE 2 - 15: REVERSE TUNNELING ROUTING SCHEME ............................................................................16 FIGURE 2 - 16: STATIC NAT .........................................................................................................................19 FIGURE 2 - 17: DYNAMIC NAT.....................................................................................................................20 FIGURE 2 - 18: NETWORK ADDRESS PORT TRANSLATION ...........................................................................21 FIGURE 2 - 19: NETWORK DRIVER INTERFACE SPECIFICATION ...................................................................22 FIGURE 2 - 20: TRANSPORT DRIVER INTERFACE ..........................................................................................23 FIGURE 2 - 21: USER-MODE NETWORK ARCHITECTURE DIAGRAM .............................................................24 FIGURE 2 - 22: TRANSPORT SERVICE PROVIDER ..........................................................................................25 FIGURE 2 - 23: WINDOWS 2000 PACKET FILTER INTERFACE EXAMPLE.......................................................25 FIGURE 2 - 24: KERNEL-MODE NETWORK ARCHITECTURE DIAGRAM .........................................................26 FIGURE 2 - 25: WINDOWS 2000 FILTER-HOOK DRIVER EXAMPLE ...............................................................28 FIGURE 2 - 26: DIRECT AND INDIRECT DELIVERIES .....................................................................................30 FIGURE 2 - 27: ARP PROCESS .......................................................................................................................35 FIGURE 2 - 28: TCP/IP IN THE WINDOWS NETWORK ARCHITECTURE .........................................................35 FIGURE 3 - 1: WLAN/GPRS INTEGRATION WITH TIGHT COUPLING............................................................37 FIGURE 3 - 2: WLAN/GPRS INTEGRATION WIT LOOSE COUPLING .............................................................38 FIGURE 3 - 3: NETSWAP SYSTEM ARCHITECTURE .......................................................................................39 FIGURE 3 - 4: NDIS NETSWAP DRIVER ........................................................................................................40 FIGURE 3 - 5: UML SEQUENCE DIAGRAM FOR NETSWAP............................................................................41 FIGURE 3 - 6: DYNAMICS MOBILE IP SYSTEM ARCHITECTURE ...................................................................43 FIGURE 3 - 7: HANDOFF SCRIPT WITH SELECTION ALGORITHM...................................................................44 FIGURE 3 - 8: PRIORITY INTERFACE DETERMINATION ALGORITHM ............................................................45 FIGURE 3 - 9: IOTA GATEWAY SOFTWARE ARCHITECTURE........................................................................45 FIGURE 3 - 10: IOTA CLIENT SOFTWARE ARCHITECTURE...........................................................................46 FIGURE 3 - 11: IOTA CLIENT INTERFACE SELECTION ALGORITHM .............................................................46 FIGURE 3 - 12: MOBILE IP NAT TRAVERSAL PROBLEM ..............................................................................47 FIGURE 3 - 13: US PATENT MOBILE IP NAT TRAVERSAL SCHEME .............................................................48 FIGURE 3 - 14: IP-IN-UDP ENCAPSULATION AND HEADER FORMAT ...........................................................49 FIGURE 3 - 15: IETF MOBILE IP NAT TRAVERSAL SCHEME .......................................................................49 FIGURE 3 - 16: UDP TUNNEL REQUEST EXTENSION FORMAT .....................................................................50 FIGURE 3 - 17: UDP TUNNEL REPLY EXTENSION FORMAT ..........................................................................50 FIGURE 4 - 1: RADIO MODILE IP SYSTEM ARCHITECTURE ..........................................................................53 FIGURE 4 - 2: LAN-WLAN ROAMING SCENARIO ........................................................................................54 FIGURE 4 - 3: LAN HANDOFF TO WLAN MESSAGE FLOW ..........................................................................55 FIGURE 4 - 4: WLAN HANDOFF TO LAN MESSAGE FLOW ..........................................................................56 FIGURE 4 - 5: WLAN-GPRS ROAMING SCENARIO ......................................................................................57 ix.

(11) FIGURE 4 - 6: WLAN HANDOFF TO GPRS MESSAGE FLOW ........................................................................58 FIGURE 4 - 7: GPRS HANDOFF TO WLAN MESSAGE FLOW ........................................................................59 FIGURE 4 - 8: RIOMIP CLIENT SOFTWARE ARCHITECTURE ........................................................................60 FIGURE 4 - 9: NDISFLT DRIVER WORKING FLOWCHART .............................................................................61 FIGURE 4 - 10: IPFLT DRIVER WORKING FLOWCHART ................................................................................62 FIGURE 4 - 11: WINDOWS MEDIA SENSE ......................................................................................................63 FIGURE 4 - 12: MOBILE IP SERVICE INTERMEDIATE DRIVER WORKING FLOWCHART ................................64 FIGURE 4 - 13: NDISPROT PROTOCOL DRIVER WORKING FLOWCHART ......................................................66 FIGURE 4 - 14: RIOMIP MOBILITY MANAGEMENT CLIENT SOFTWARE COMPONENTS ..............................67 FIGURE 4 - 15: ADAPTER MANAGEMENT MODULE WORKING FLOWCHART ...............................................69 FIGURE 4 - 16: MOBILE IP TUNNELING MODULE WORKING FLOWCHART ..................................................71 FIGURE 5 - 1: MOBILE IP ALTERNATIVE TUNNELING SYSTEM ARCHITECTURE ..........................................74 FIGURE 5 - 2: ALTERNATIVE MOBILE IP NAT TRAVERSAL SCHEME ..........................................................75 FIGURE 5 - 3: IP-IN-IPHO ENCAPSULATION AND HEADER FORMAT..............................................................76 FIGURE 5 - 4: IP HEADER OPTION TYPE FIELD FORMAT ..............................................................................77 FIGURE 5 - 5: NETWORK ADDRESS SWAP MODULE OUTBOUND PACKET PROCESS ....................................77 FIGURE 5 - 6: NETWORK ADDRESS SWAP MODULE INBOUND PACKET PROCESS ........................................78 FIGURE 5 - 7: REGISTRATION REQUEST/REPLY MESSAGE WITH IP HEADER OPTION..................................80 FIGURE 5 - 8: IP-IN-IPHO TUNNELING AND IP-IN-IP REVERSE TUNNELING .................................................81 FIGURE 6 - 1: RADIO MOBILE IP IMPLEMENTATION NETWORK TOPOLOGY ................................................84 FIGURE 6 - 2: NDIS PACKET STRUCTURE ....................................................................................................85 FIGURE 6 - 3: NDISFLT DRIVER FILTER PACKET FUNCTION ........................................................................86 FIGURE 6 - 4: NDISFLT DRIVER CALLBACK FUNCTION INTERFACE.............................................................86 FIGURE 6 - 5: IPFLT DRIVER CALLBACK FUNCTION.....................................................................................89 FIGURE 6 - 6: IPFLT DRIVER PACKET BUFFER DATA STRUCTURE ...............................................................89 FIGURE 6 - 7: MOBILE IP SERVICE INTERMEDIATE DRIVER INTERNAL FUNCTIONS ....................................90 FIGURE 6 - 8: ROUTING TABLE BEFORE APPLYING MOBILE IP SERVICE INTERMEDIATE DRIVER ...............91 FIGURE 6 - 9: ROUTING TABLE AFTER APPLYING MOBILE IP SERVICE INTERMEDIATE DRIVER .................91 FIGURE 6 - 10: NDISPROT PROTOCOL DRIVER I/O CONTROL HANDLE FUNCTION ......................................93 FIGURE 6 - 11: NDISPROT PROTOCOL DRIVER NDISMINDICATESTATUS HANDLE FUNCTION ....................94 FIGURE 6 - 12: MOBILE NODE IP ADDRESS CONFIGURATION ......................................................................95 FIGURE 6 - 13: ROUTING TABLE UNDER HOME NETWORK ..........................................................................96 FIGURE 6 - 14: ROUTING TABLE UNDER FOREIGN NETWORK (LAN) ..........................................................98 FIGURE 6 - 15: ROUTING TABLE UNDER FOREIGN NETWORK (WLAN).....................................................100 FIGURE 6 - 16: HANDOFF DECISION ALGORITHM.......................................................................................101 FIGURE 6 - 17: MOBILE IP STATUS DETERMINATION ALGORITHM ............................................................101 FIGURE 6 - 18: HOME AGENT CONFIGURATION SNAPSHOT .......................................................................102 FIGURE 6 - 19: MOBILE NODE CONFIGURATION (LAN/WLAN) SNAPSHOT .............................................103 FIGURE 6 - 20: MOBILE NODE INITIAL WITH LAN ADAPTER SNAPSHOT ...................................................103 FIGURE 6 - 21: MOBILE NODE HANDOFF TO WLAN ADAPTER SNAPSHOT ...............................................104 FIGURE 6 - 22: MOBILE NODE HANDOFF TO LAN ADAPTER SNAPSHOT ...................................................104 FIGURE 6 - 23: MOBILE NODE CONFIGURATION (WLAN/GPRS) SNAPSHOT ............................................105 FIGURE 6 - 24: MOBILE NODE INITIAL WITH WLAN ADAPTER SNAPSHOT ...............................................105 FIGURE 6 - 25: MOBILE NODE HANDOFF TO GPRS ADAPTER SNAPSHOT .................................................106 FIGURE 6 - 26: MOBILE NODE HANDOFF TO WLAN ADAPTER SNAPSHOT ...............................................106 FIGURE 6 - 27: ALTERNATIVE TUNNELING IMPLEMENTATION NETWORK TOPOLOGY ..............................109 FIGURE 6 - 28: IP HEADER OPTION DATA STRUCTURE DEFINITION ..........................................................110 FIGURE 6 - 29: TUNNELING DEVICE PARAMETER ......................................................................................111 FIGURE 6 - 30: TUNNELING DEVICE INTERNAL FUNCTION ........................................................................111 FIGURE 6 - 31: DYNAMICS INTERNAL FUNCTION I.....................................................................................112 FIGURE 6 - 32: DYNAMICS INTERNAL FUNCTION II ...................................................................................113 FIGURE 6 - 33: IPV4 TRAVERSAL DIAGRAM ...............................................................................................113 FIGURE 6 - 34: NAT INTERNAL FUNCTION .................................................................................................114 x.

(12) FIGURE 6 - 35: HOME AGENT CONFIGURATION SNAPSHOT .......................................................................115 FIGURE 6 - 36: MOBILE NODE CONFIGURATION SNAPSHOT ......................................................................115 FIGURE 6 - 37: PACKET DUMP ON EXTERNAL /INTERNAL INTERFACE.......................................................116 FIGURE 7 - 1: BANDWIDTH UTILIZATION COMPARISON ON PACKET LENGTH NOT EXCEEDING MTU......119 FIGURE 7 - 2: BANDWIDTH UTILIZATION COMPARISON ON PACKET LENGTH EXCEEDING MTU .............120 FIGURE 7 - 3: TCP THROUGHPUT ESTIMATION TESTBED ..........................................................................121 FIGURE 7 - 4: TCP THROUGHPUT ESTIMATION RESULT ............................................................................122. xi.

(13) Tables TABLE 2 - 1: PRIVATE IP ADDRESSES TABLE ...............................................................................................18 TABLE 2 - 2: WINDOWS-BASED HOST ROUTING TABLE ...............................................................................31 TABLE 2 - 3: WINDOWS-BASED ARP CACHE TABLE....................................................................................34 TABLE 6 - 1: HOME AGENT HARDWARE REQUIREMENT TABLE ..................................................................82 TABLE 6 - 2: MOBILE NODE HARDWARE REQUIREMENT TABLE .................................................................82 TABLE 6 - 3: HOME AGENT SOFTWARE REQUIREMENT TABLE ...................................................................83 TABLE 6 - 4: MOBILE NODE SOFTWARE REQUIREMENT TABLE ..................................................................83 TABLE 6 - 5: IPFLT DRIVER DEVICE I/O CONTROL TABLE ..........................................................................87 TABLE 6 - 6: NDISPROT PROTOCOL DRIVER DEVICE I/O CONTROL TABLE ................................................92 TABLE 6 - 7: HOME AGENT HARDWARE REQUIREMENT TABLE ................................................................107 TABLE 6 - 8: MOBILE NODE HARDWARE REQUIREMENT TABLE ...............................................................107 TABLE 6 - 9: NETWOK ADDRESS TRANSLATOR HARDWARE REQUIREMENT TABLE .................................108 TABLE 6 - 10: HOME AGENT SOFTWARE REQUIREMENT TABLE ...............................................................108 TABLE 6 - 11: HOME AGENT SOFTWARE REQUIREMENT TABLE ...............................................................108 TABLE 6 - 12: HOME AGENT SOFTWARE REQUIREMENT TABLE ...............................................................109 TABLE 6 - 13: IP-IN-IPHO TUNNELING DEVICE I/O CONTROL TABLE ........................................................110. xii.

(14) Chapter 1. Introduction. Section 1.1. Motivation. 被稱為 GPRS 之父的芬蘭赫爾辛基科技大學 Hannu Kari 教授在 2001 年 7 月來台的一場演講中指出，由於第三代行動通訊系統的投入成本過高且推展不易，未來的行動數據服務將是以 GPRS 加 WLAN 為主流的解決方案。雖然 Hannu Kari 所提出論點並不為 3G 業者所認同，不過在 3G 短期內無法落實大量商業化下，為滿足消費者對於隨身攜帶與高頻寬的需求，手機與 WLAN 的結合似乎成為各大半導體業者的努力方向。無論是檢視市面上現有的消費性產品或是政府與業界所大力推動的雙網整合計畫，都在在地證實 Hannu Kari 教授的論點。就技術而言，GPRS 的傳輸距離可達 10 公里，理論速度為 144Kbps。而相較於 WLAN 傳輸速率高，如 802.11g 可達 54Mbps，但傳輸距離短只有數百公尺。除此之外，WLAN 採用免費的 2.4GHz 頻段，整體建置成本低，因此收費低廉。而 GRRS 雖然網路成本高收費貴，但範圍廣且安全性高。由此可看出，此兩異質性的網路各有其優缺點與適用的空間。倘若能加以整合便能讓使用者根據需求及環境選用最適當的網路，這也就是驅使我們整合兩大技術的原因所在。順著該趨勢的發展，現下無論是筆記型電腦，平板電腦，個人數位助理或是智慧型手機在硬體上都已具備雙網甚至是多網的能力。然而令人失望的是雖然硬體已趨成熟，但是仍未見到一套可統整使用這些異質網路介面卡的軟體。於是乎便激發了我們發展異質網路漫遊系統的整合平台，藉由該平台希望能夠讓使用者輕易的管理與使用其擁有的多張網路卡，不僅如此，我們還期望保障使用者在這些異質網路間漫遊(切換)時不造成斷線。. Section 1.2. Approach. 在上一節中，我們已經清楚的瞭解我們的需求所在，因此在本節中將簡單的敘述我們如何達該目的。首先，在開發平台的部分，我們將選用被現今一般使用者所最為熟悉的微軟作業系統 Windows XP。而此平台將提供的功能則包含有收集網路卡的狀態資訊、自動選擇最適當的網路卡、由選定網路卡繞送/擷取往返的封包以及維持行動裝置於漫遊時的連線等。接著在細部的考量上，我們發現到網路介面的選擇上由於必須考量其連線狀態、網路頻寬、計費標準與使用者偏好等複雜的因素，因此我們僅將重心專注於網路卡管理與路由等方面的技術探討。此外，驗證我們的方法，我們將會實作一個運作於用戶模式下的簡單切換抉擇演算法軟體模組來為行動裝置自動選擇一張適當的網路卡。為了做出正確的選擇，切換抉擇模組必須取得網路卡的相關狀態。而這些資訊包含有 Layer-2 的連結狀態、訊號強度等以及 Layer-3 的 DHCP 位址、路由表等。所以在這部分將會去瞭解如何自 Windows XP 的網路核心架構中取得這些資訊。. 1.

(15) 其次，在行動管理的部分我們會採用行動網際網路協定的配置轉交位址模式來支援不斷線的漫遊服務。採用該模式的原因在於行動端可以視每個漫遊的網路僅為一個存取網路，而無須網路服務提供者的任何支援。不過，在此碰到的第一個問題就是如何解決該協定中所規定的行動端必須自行處理收送封包的封裝/拆裝動作，換句話說，我們要先能夠攔截原本自應用程式所發送以及由網路卡所接收的封包後才能進行後續的動作。針對這個問題，我們會去瞭解 Windows XP 內部的網路核心架構尋求可能的解決方案。第二個問題則是如何管理行動端的家位址與配置轉交位址。關於這點我們則是希望能讓家位址設定在行動端的其中一張網路卡上，並且永遠維持該設定的存在，同時該網路卡還能透過 DHCP 協定去取得漫遊網路當地的配置轉交位址。另一方面，在採用行動網際網路協定的同時還會碰到的一個問題就是該協定無法穿越現今普遍存在於網路上的網路位址轉譯器。對於該問題在 IETF 所提出的解決方案中是將封裝的層級拉到傳輸層來克服，但我們認為這樣有違行動網際網路協定在最初的設計理念。因此，在最後的部分我們會試著回到網路層重新地解決該問題，並證實我們所提出的方法比原有的解決方案具備更佳的傳輸效能。最後，在建立起以上這些背景知識後，我們會將所需要的功能做成一個個小的軟體元件，最後以元件組合式的架構建構出成我們所需要的平台。. Section 1.3. Synopsis. 本篇論文在稍後的章節編排與簡述如下：第二章為背景知識的概述，包含行動網際網路協定，網路位址轉譯器以及微軟視窗作業系統下的封包路由與擷取技術。第三章接著介紹與本論文相關的文獻，其中有無線網路整合技術與行動網際網路協定穿越網路位址轉譯器方法等兩部分。第四章便說明我們所開發的整合平台之系統架構與其內各個軟體元件。第五章則是我們所提出用來改進原有行動網際網路協定穿越網路位址轉譯器的方法介紹。緊接著，第六章將詳細地解說如何實作出以上兩個章節所介紹的系統與方法。並在以實際程式所展示的實例之後，於第七章做個討論與效能評估。最後，第八章為本篇論文的總結與未來的研究方向。. 2.

(16) Chapter 2. Background Material. Section 2.1. Mobile IP. 在 90 年代初期，網際網路工程工作特別小組(Internet Engineering Task Force，IETF)於網際網路領域(Internet Area)下創立了一個名為”IP Routing for Wireless/Mobile Hosts (Mobile IP)”的新工作群組(Working Group)，該群組將發展一套行動性的網際網路協定(IP Mobility)機制使得行動用戶(Mobile User)無論在何處連上網際網路皆可使用相同的網際網路位址。其目的是當行動用戶漫遊於不同的網路時能保持在線狀態並維持原有的網際網路連線(IP Connectivity)。而這些不同的網路是可以基於不相同的存取技術(Access Technology)，因此這項機制必須獨立於其下的鏈結層 (Link Layer)技術。第一版的規格 RFC 2002 “IP Mobility Support” [8] 於 1996 年的十月被發表，之中提出了一個稱為”Mobile IP for IPv4”的新協定，該協定實際上是正規網際網路協定的一種延伸(Extension)。在 2002 年的一月，新版的規格 RFC 3220 “IP Mobility Support for IPv4” [15] 淘汰了舊有的 RFC 2002，而隨後在八月所發表的 RFC 3344 “IP Mobility Support for IPv4” [16] 也翻新了 RFC 3220。 RFC 3344 目前的狀態為”被提議的標準(Proposed Standard)”，意味著它將進入成為”網際網路標準(Internet Standard)”的程序，但由於仍未完全成熟，將來也有可能更進一步的發展。在此同時，該工作群組也致力於解決一些偶然碰到的特殊問題。在他們的網站中可以找到發佈於草案(Draft)內的建議解決方案。其中有些問題將在稍後的章節作討論。而在 IPv6 方面，工作群組發展了一套類似的機制，該機制被發佈於名為”Mobility Support in IPv6”的草案內。最主要的差異點在於它將會被整合進 IPv6 的標準，而非如同 IPv4 一般，行動性的支援(Mobility Support)只是選擇性的。對於行動用戶來說，他將需要特殊的客戶端軟體來使用 Mobile IP。行動性的支援其需求存在於那些被網際網路用戶漫遊於不同的網路下所使用的服務內。例如你正在下載一個大的檔案或是正在看或聽一個媒體串流，你將不希望因為在不同的網路之中移動造成這個連線被中斷。同樣情況也發生在當你使用網際網路語音(Voice-over-IP，VoIP)時，你不會想要每換一次網路就再次地重新建立你的通話。另一個例子是當行動端(Mobile Node)作為伺服器時，必須用相同的網際網路位址被它的客戶端所找到。因此，在用途上大致可分為兩基本面： 1. 可利用性(availability)，行動伺服器必須被一個永不改變的網際網路位址所找到 2. 連續性(continuity)，當變更網路的接點(point of attachment)時維持網際網路的連線 Mobile IP 是一個宏觀移動(macro mobility)的解決方案，它能處理在不同存取技術或相異第三層網路間的網際網路換手。但它並不適合於第二層基地台(cell)間的換手，也就是所謂的微觀移動 (micro mobility)。 Mobile IP 近年來逐漸在市場上產生影響力，其中 cdma2000 社群(cdma2000. 3.

(17) 是北美版本的第三代行動電話系統，由 3GPP2 組織所制定)是推展建置的其中一個主要原動力。在該規格 [22] 中，Mobile IP 被選為當作 cdma2000 封包資料用戶的行動網路協定。在本節中將根據 RFC 3344 介紹 Mobile IP 這個協定。首先 2.1.1 是一個概觀的描述，接著 2.1.2 與 2.1.3 將會詳細解釋細節。最後一些特殊的問題會在 2.1.4 做討論。. 2.1.1. Mechanism. 在網際網路協定(Internet Protocol, IP) [2] 下的網路，路由(Routing)是根據固定不動的 IP 位址。一個網路上的端點(Node)可以被正常的 IP 路由所遶送是根據它在網路上所被分配的 IP 位址。 IP 位址由兩部分所構成：網路前置碼(Network Prefix)與當地位址(Local Address)。由分屬於不同網路下的端點 A 送給端點 B 的 IP 封包可以被正確地路由到正確的網路是根據其網路前置碼，也就是 IP 位址的第一部分。當端點 B 經過移動並經由別於家網域(Home Network)的網路連上網際網路，它可能會得到一個與其家位址(Home Address)不同的 IP 位址。而 Mobile IP 就是使其他端點都可以用端點 B 原本的家 IP 位址與其連線的機制。再者，有了 Mobile IP，端點 B 能用它原有的家 IP 位址當作來源位址。所以說 Mobile IP 為行動端提供了與它們的網際網路接點無關的透明化 IP 路由。根據 RFC 3344，下述將說明幾項定義，其中包含了 Mobile IP 的三個主要構成要素：家代理器(Home Agent)，外地代理器(Foreign Agent)與行動端。 ● 行動端(Mobile Node, MN) 行動端是一個漫遊於不同網路下並且可以使用相同 IP 位址的主機(Host)或是路由器 (Router)。行動端可以改變其網際網路的接點而不必更動它固定的 IP 位址，也就是所謂的家位址。 ● 家網域(Home Network, HN) 行動端的家網域是指用家位址作為目的 IP 封包依正常 IP 路由所被送達的網路。 ● 家位址(Home Address) 行動端的家位址是一個分配給行動端的固定 IP 位址。它是維持不變的並且屬於家網域的網路。行動端將永遠使用這個位址當作來源位址，甚至是正當它在漫遊時。 ● 家代理器(Home Agent, HA) 行動端的家代理器是一個在家網域的主機或是路由器。當行動端離開家網域的時候，它攔截所有送往行動端的 IP 數據資料(Datagram)並經過通道技術(Tunnel)將它們傳給行動端。再者，家代理器還執行某些驗證(Authentication)與管理(Administration)的功能。 ● 通訊端(Correspondent Node, CN) 通訊端是一個行動端正在與之通訊的任意端點。. 4.

(18) ● 外地網域(Foreign Network, FN) 外地網域是指行動端的家網域之外的網路。 ● 外地代理器(Foreign Agent, FA) 外地代理器是一個在外地網域的主機或是路由器，它提供路由服務給已註冊的行動端。外地代理器把家代理器經過通道技術傳送過來的 IP 數據資料進行拆封(Detunnel)並發送給註冊的行動端。再者，外地代理器為行動端執行驗證與管理的功能。對於行動端來說，它被當作預設路由器(Default Router)。外地網域不必要存在一個外地代理器來使得 Mobile IP 可以運行。 ● 行動代理器(Mobility Agent) 行動代理器是一個對於家代理器與外地代理器的通稱。 ● 轉交位址(Care-of Address, COA) 轉交位址是家代理器把數據資料經過通道技術要送給行動端所預定到達的 IP 位址。這個通道的終止點可以是行動端所註冊的外地代理器，或者是當沒有可用的外地代理器時，也可以是行動端本身。對後者來說，這個轉交位址又被稱為配置轉交位址(Colocated COA)。它是一個在所拜訪的外地網域上暫時分配給行動端的 IP 位址，例如透過動態主機設定協定(Dynamic Host Configuration Protocol, DHCP) [12]。然後，行動端將會自行對封裝過的數據資料進行拆封。 ● 行動連結資訊(Mobility Binding) 指的是行動端的家位址，轉交位址與剩餘註冊有效時間(Lifetime)的連結。行動連結資訊被儲存在家代理器上的註冊列表內。上述的定義已經透露很多關於 Mobile IP 的機制。為了更進一步的解釋 Mobile IP 的機制，兩種基本的運作模式範例將在以下作說明。在這些範例中所使用的 IP 位址並非真實的，純粹為了例證。外地代理器轉交位址模式 (Foreign Agent Care-Of Address Mode) 此模式描述了一個使用家代理器與外地代理器的標準配置範例。家網域(140.113.215.0/24)透過路由器 (140.113.215.254) 連接到網際網路，詳見圖 2-1 。行動端固定的家 IP 位址是 140.113.215.207，而家代理的 IP 位址是 140.113.215.206。. 5.

(19) 82.50.119.117 82.50.119.117. Correspondent Node. 140.113.215.206 140.113.215.206. 140.113.215.0/24 140.113.215.254 140.113.215.254 Home Agent. Mobile Node. Home Network 140.113.215.207 140.113.215.207. Figure 2 - 1: Home Network Scenario. 行動端透過接收來自其家代理器的特定訊息：家代理器公告(Home Agent Advertisement)，來判斷是否位在家網域內。大致上來說，家代理器公告是由家代理器所送出，並且帶有家代理器的 IP 位址，有效期限以及家代理器關於 Mobile IP 服務與能力的參數。當行動端在家網域內時，它能使用正常的 IP 路由與它擁有的家位址。在這狀況下，家代理器只作為讓行動端判斷所在位置的依據並不干涉其 IP 資料封包的路由。假設當行動端漫遊到一個外地網域 140.113.24.0/24，如圖 2-2 所示。行動端可以藉由判斷目前所聆聽的代理器之公告有效期限到期後，是否沒有再收到從同一個代理器來的新公告得知自己的移動。另一種移動偵測的方式是基於網路前置碼的不同。行動端藉由接收到外地代理器公告(Foreign Agent Advertisement)訊息發現可用的外地代理器，訊息中提供了一個或多個轉交位址給行動端。現在行動端得知了外地代理器與它可用的轉交位址，下一步就是透過外地代理器向家代理器註冊。這個註冊的必要性在於在家代理器上產生一個行動連結資訊，用來控制家代理器與轉交位址間的通道。該通道將被作為轉交送往行動端的 IP 封包之用。為了維護這個通道，行動連結資訊必須在註冊有效期限到期前被更換或更新。 Mobile IP 的註冊程序採用要求-回覆(Request-Reply)模式。假如行動端透過外地代理器註冊，那麼外地代理器將會處理註冊要求訊息(Registration Request Message)然後轉交給家代理器。當註冊成功，家代理器會回覆給外地代理器，它在轉交回行動端之前會再一次的處理這個註冊回覆訊息 (Registration Reply Message)。所有的註冊訊息都是被經過驗證保護的避免被不必要的干預與濫用。. 6.

(20) 圖中的箭頭表示了 IP 封包如何在通訊端(82.50.119.117)與行動端間被路由。實線部分是通訊端送給行動端的封包，虛線的部分是由行動端送給通訊端。通訊端用行動端的家位址 (140.113.215.207)作為 IP 封包送達的地點。這些封包基於網路前置碼 140.113.215.0 被遶送到行動端的家網域。在家網域內，家代理器攔截了這些封包並透過通道技術將它們往轉交位址送去，也就是往外地代理器。外地代理器對這些被封裝過的封包進行拆裝後，把它們丟在行動端所在的鏈結上。如此一來，當行動端在連接在外地網域的時候就能收到送往它的家位址的 IP 封包。由行動端送往通訊端的封包可以經由正常的 IP 路由。行動端用通訊端的 IP 位址 (82.50.119.117) 作為封包送達的地點。它把家位址 140.113.215.207 當作 IP 封包內的來源位址，基本上這樣對網路的拓樸來說是不對的。此時，外地代理器會作為行動端的預設路由器/閘道器。這樣的路由方式被稱作三角式路由(Triangular Routing)。從通訊端到行動端透過通道的路徑不相同於行動端到通訊端的路徑，如此形成了一個三角形。 82.50.119.117 82.50.119.117. Correspondent Node. 140.113.215.206 140.113.215.206. 140.113.24.68 140.113.24.68. 140.113.215.0/24. 140.113.24.0/24. Tunnel Home Agent. Mobile Node. Mobile Node. Home Network. Foreign Agent. Foreign Network 140.113.215.207 140.113.215.207. Figure 2 - 2: Foreign Network Scenario under FA CoA Mode. 配置轉交位址模式 (Co-located Care-Of Address Mode) 此模式是一個不使用外地代理器的標準範例。假設行動端連接到外地網域 140.113.24.0/24，見圖 2-3。這個外地網域沒有設置外地代理器，所以行動端將不會接收到任何外地代理器公告。在這範例下，行動端透過 DHCP 得到一個 IP 位址 140.113.24.23。行動端能把這個位址當作轉交位址，因為它被分配到行動端的一張介面卡上，這個位址被稱為配置轉交位址。為了產生行動連結資訊，行動端直接地向家代理器(140.113.215.206)註冊。家代理器此時便可以建立一條往轉交位址,的通道，在這個例子中其實就是行動端本身。. 7.

(21) 同樣的，圖中的箭頭表現了一個路由的例子。與外地代理器轉交位址模式的情況可說是大同小異，除了通道的終點是在行動端之外，也就是說，行動端會自行對封包作拆封。因此，行動端可以藉由兩個 IP 位址被找到： 140.113.215.207 被用來讓資料穿過通道以及 140.113.24.23 被用作 Mobile IP 的註冊。而後者是通道的終點。 82.50.119.117 82.50.119.117. Correspondent Node 140.113.215.207 140.113.215.207 140.113.24.23 140.113.24.23. 140.113.215.206 140.113.215.206. 140.113.215.0/24. 140.113.24.0/24. Tunnel Mobile Node. Home Agent. DHCP Server. Mobile Node. Home Network. Foreign Network. Figure 2 - 3: Foreign Network Scenario under Co-located CoA Mode. 2.1.2. Signaling. 在 Mobile IP 的協定中定義了幾種特定的訊息，這些訊息主要是為了兩項目的：尋找行動代理器及其服務與向行動端的家代理器註冊。在本段中將依序詳細探討關於這兩種訊息。代理器公告與請求 (Agent Advertisements and Solicitations) 在前述的範例中已經提到家代理器與外地代理器使用特定訊息來向鏈結上的所有端點表明它們的存在以及 Mobile IP 的需求與能力。這些訊息就是所謂的代理器公告。由家代理器所送出的稱為家代理器公告，而自外地代理器送出的則稱作外地代理器公告。行動代理器用廣播的方式送出這些訊息，而且只送到它們所服務的鏈結上。一般來說，每隔一段固定的時間就會送出公告，但這並非是必須的。因此，代理器公告可被所謂的代理器請求所要求。當行動端廣播了一個代理器請求訊息到鏈結上，所有在該鏈結上可用的行動代理器都必須回覆一個代理器公告。在這個情形之下，公告訊息應該被直接送往要求的行動端，也就是並非透過廣播的方式。代理器公告是由一個行動代理器公告延伸加上一個路由器公告訊息所組成。路由器公告訊息定義在網際網路控制訊息協定的路由器探索協定(ICMP Router Discovery Protocol, IRDP) [3] 中，圖 2-4。. 而行動代理器延伸訊息則包含了關於行動代理器服務的資訊，圖 2-5。它宣佈了發送的. 行動代理器是否作為外地代理器，家代理器或者兩者皆是。它通知了行動端關於它的服務，所支. 8.

(22) 援的通道模式以及如果是有外地代理器功能的時候，它公告了一個或多個轉交位址。代理器公告沒有經過驗證或加密。. Figure 2 - 4: ICMP Router Advertisement Format. Figure 2 - 5: Agent Advertisement Extension Format. 代理器請求訊息就是把 TTL 欄位設為 1 的網際網路控制訊息協定路由器請求訊息(ICMP Router Solicitation)，圖 2-6。所以它只在被送出的子網域中有效。此外行動代理器請求訊息中不包含任何特定的 Mobile IP 參數。. Figure 2 - 6: ICMP Router Solicitation Format. 註冊要求與回覆 (Registration Request and Reply) 當行動端漫遊到一個外地網域的時候，Mobile IP 使用了一個通道來重新導向送往行動端的 IP 封包。這個通道是被家代理器與行動端所建立與控制的，是否與外地代理器連結則是選擇性的。這些控制資訊是藉由註冊訊息來交換。而 Mobile IP 註冊訊息則是使用用戶數據資料協定 (User. 9.

(23) Datagram Protocol, UDP) [1]。公認的埠號 434 已經被網際網路號分配機構(Internet Assigned Number Authority, IANA)分配作為這樣的用途 [5]。註冊要求與註冊回覆是由附加一個或多個延伸的標準固定部分所構成，如圖 2-7 與 2-8。. Figure 2 - 7: Registration Request Message Format. Figure 2 - 8: Registration Reply Message Format. 註冊要求與註冊回覆的固定部分只差在一個位元組與一個欄位。固定部分一定包含了用來識別行動端的行動端家位址，用來識別家代理器的家代理器 IP 位址以及一個用來識別註冊訊息本身的識別欄位，它被用來匹配註冊要求與註冊回覆。在相異的位元組中，註冊要求包含了行動端可以要求特定 Mobile IP 服務的旗標。註冊回覆則是在這個位元組中填入家代理器的回覆代碼，它通知了行動端關於這個註冊的狀態。如此一來行動端便能核對這個註冊是否已經被接受並且在錯誤代碼被回報時採取適當的行動。而對於這個相異的欄位只存在註冊請求中，它存放了一個轉交位址用來告知家代理器通道的終點。在 RFC 3344 中定義了許多種類的延伸，其中最重要的就是驗證延伸，見圖 2-9。這個延伸確保了訊息交換的安全。每個行動端與它的家代理器間都有一個安全性關聯 (Security 10.

(24) Association)。這個關聯是被一個 32 位元的數字所識別，也就是安全性參數索引(Security Parameter Index, SPI)。選擇性地，行動端可與外地代理器間有一個安全性關聯，外地代理器也可與家代理器間有安全性關聯，而這些安全性關聯都被各自的 SPI 所表明。安全性關聯中包含了一個機密，一個 128 位元的共享金鑰(Shared Key)，其被運用在自註冊訊息中的特定欄位計算出一個驗證元(Authenticator)。驗證元是一個數學上的訊息摘要，根據的是 HMAC-MD5 演算法 [11]。這是一種只讓共享金鑰的擁有者閱讀的簽章方式。它必須使家代理器與行動端免受來自其他端點的偽造註冊訊息。同時還有另一種在註冊程序中必須被保護避免的攻擊形式：重送攻擊 (Replay Attack)。在註冊訊息固定部分中的識別欄位包含了一個時間戳記(Timestamp)或是亂數 (Nonce)來確保一個註冊訊息僅有效一次。這將會避免當惡意的端點重送舊訊息時所造成的困擾。. Figure 2 - 9: Authentication Extension Format. 由於每個註冊訊息都是由跟隨在固定部分之後的一個或更多的延伸所組成。驗證延伸必須放置在所有其他延伸之後來保護它們，因為訊息摘要由 UDP 承載所計算出，其中包含了所有之前的延伸。驗證延伸被放置的順序與可用的安全性關聯有關。在下面的例子中將會闡明這一點。圖 2-10 代表一個由行動端經由外地代理器送往家代理器的註冊要求。在這例子中出現了三個安全性關聯，一個是在行動端與家代理器間(MN-HA, MH)，一個選擇性的在行動端與外地代理器間(MNFA, MF)以及另一個選擇性的在外地代理器與家代理器間(FA-HA, FH)。它們每個都有屬於自己的共享金鑰來計算或核對相關的驗證延伸。. 11.

(25) A. B. Mobile Node. C. Foreign Agent. Home Agent. IP header. IP header. UDP header. UDP header. Mobile IP reg. req.. Mobile IP reg. req.. MN-HA ext. (opt.). MN-HA ext. (opt.). MN-HA auth ext.. MN-HA auth ext.. MN-FA ext. (opt.). FA-HA ext. (opt.). MN-FA auth ext.. FA-HA auth ext.. A B. A C. Figure 2 - 10: Authentication Extension Order. 當註冊請求封包由行動端被送往外地代理器時，行動端運用箭號 A 所標示的資料計算行動端與家代理器間的驗證元，換言之就是註冊要求，選擇性的 MH 延伸以及前面部分的 MH 驗證延伸 (不包含驗證元本身)。行動端與外地代理器間的驗證元是利用箭號 B 所標示的資料被計算出來。當封包到達外地代理器，外地代理器移除所有的 MF 延伸並核對行動端與外地代理器間的驗證元。如果正確無誤，它會用箭號 C 所標示的資料計算外地代理器與家代理器間的驗證元。接著，外地代理器會把它加入封包中並送往家代理器。家代理器首先會移除所有的 FH 延伸並核對外地代理器與家代理器間的驗證元，之後再移除所有的 MH 延伸並核對行動端與家代理器間的驗證元。註冊回覆訊息也是以類似的方式被驗證。在這方法下，安全性關聯是彼此獨立的。要注意到圖中也展示了一些選擇性未被定義的延伸(MH, MF, FH)用來指出它們被放置的位置。前面已經討論了註冊訊息以及牽扯到的安全議題。接下來將深入註冊程序本身。註冊程序的目的是提供家代理器與選擇性的外地代理器正確的資訊來初始化通道。對家代理器來說，這些資訊被存在行動連結資訊中。一個服務數個行動端的外地代理器能對多個家代理器註冊並且對每個註冊保有一個訪客名單(Visitor List)。當行動端註冊時，它送出一個註冊要求給外地代理器。在核對選擇性的 MF 驗證延伸過後，外地代理器產生一個待處理的訪客名單登記(Pending Visitor List Entry)。接著選擇性的加入 FH 驗證延伸並把訊息轉交往家代理器。待處理的訪客名單登記包含了以下項目： ● 鏈結層來源位址 ● IP 來源位址 ● IP 目的位址 ● UDP 來源埠號. 12.

(26) ● 家代理器位址 ● 識別欄位 ● 要求的註冊有效期間 ● 剩餘待處理或目前註冊的有效期間當家代理收到這個註冊要求，它先核對選擇性的 FH 驗證延伸。然後核對必要的 MH 驗證延伸。如果這些都是有效的，家代理器便為這個行動端產生一個行動連結資訊，它包含了： ● 行動端的家位址 ● 行動端的轉交位址 ● 註冊回覆中的識別欄位 ● 註冊的剩餘有效期間家代理器回覆一個註冊回覆送往外地代理器，指出這個註冊是否成功或為什麼失敗。如果這個註冊是成功的，外地代理器啟用相對應的待處理的訪客名單登記並回覆給行動端。這個回覆也是被驗證延伸所保護。現在家代理器便能建立通往轉交位址的通道。在配置轉交位址模式的情況下，註冊程序直接在行動端與家代理器之間進行，而如果是外地代理器轉交位址模式的情形，則是中間透過外地代理器。圖 2-11 表現了註冊訊息的交換與通道的建立。. Co-located COA. Foreign Agent COA. MN. FA. HA. MN. HA. Request Request. Request Reply. Reply Reply Tunnel. Tunnel. Figure 2 - 11: Registration Flow. 家代理器與外地代理器對每個行動端都會保有剩餘的註冊有效期間。行動端有責任在註冊有效期間到期前重新註冊以維護這個通道。行動連結資訊在有效期間到期後會被刪除。當行動端用要求一個註冊有效期間為零的註冊時，行動連結資訊也會被刪除。所以實際上這就是解註冊 (Deregistration)。解註冊對於同時擁有數個連結資訊並想刪除其中一個或多個的行動端來說非常有用。行動端在回到它的家網域後應該解註冊它所有的連結資訊。. 13.

(27) 2.1.3. Data Encapsulation. 在前面的段落中清楚解釋了 Mobile IP 是一種先進的路由機制，實際上就是它使用了動態的通道技術。 Mobile IP 支援了三種通道協定。基本的通道協定叫做”IP 承載 IP 封裝 (IP within IP Encapsulation)” [9]。這必須被所有的家代理器，外地代理器以及支援配置轉交位址的行動端所支援。此外，另外還有兩種通道協定被列入可供選擇： ” 最小化 IP 承載封裝 (Minimal Encapsulation within IP)” [10] 與”通用路由封裝 (Generic Routing Encapsulation, GRE)” [6]。行動端可以在註冊要求中向家代理器要求其中一種通道模式。而在外地代理器有參與的情況下，必須外地代理器有公告它支援這兩種額外的封裝行動端才可以要求。 IP 承載 IP 封裝是一種非常基本的通道模式。 IP 封包在一個稱做封裝者(Encapsulator)的端點被封裝，這也就是通道的進入點。封裝的意思是原本的 IP 封包被裝入一個新的 IP 封包內當作承載，如圖 2-12 所示。新封包的 IP 標頭稱為傳送標頭，包含了它的拆裝者的(Decapsulator)IP 位址。該端點會拆裝這個新的 IP 封包來恢復原本的 IP 封包，使得該封包能被路由到它原本的目的地。在這個通道協定下，拆裝者事實上不過就是把第一個 IP 標頭給移除，同時它也是這個通道的終點。這種通道技術的目的是把原本的 IP 封包傳送到一個中繼端點，也就是在原本的 IP 標頭中根據 IP 目的位址欄位不會被選擇到的拆裝者。在 Mobile IP 中，封裝者是家代理器，而拆裝者則是外地代理器或是行動端。. Original IP Header. Original IP Payload. Original IP Header. Original IP Payload. Tunnel Endpoint. Outer IP Header. Figure 2 - 12: IP-in-IP Encapsulation and Header Format. 14.

(28) 最小化 IP 承載封裝是一種非常類似於 IP 承載 IP 封裝的一種通道模式，見圖 2-13。差別在於最小化 IP 承載封裝不會封裝原本訊息完整的 IP 標頭，因為許多欄位與新的外層傳送標頭是重複的。在這方式下，標頭空間能被節省，導致更少的負擔。. Original IP Header. Original IP Payload. Tunnel Endpoint. Outer IP header. Minimal Encapsulate Header. Original IP Payload. Figure 2 - 13: Minimal Encapsulation and Header Format. 通用路由封裝是一個更通用的通道協定，其插入了一個額外的 GRE 標頭在原本的封包與傳送標頭之間，見圖 2-14。通用路由封裝不是特定用在封裝 IP 封包進另一個 IP 封包。它可以封裝任何協定 X 的封包進另一個協定 Y 封包的承載中。. Original IP Header. Original IP Payload. Tunnel Endpoint. Deliver (IP) Header. GRE Header. Original IP Packet. Figure 2 - 14: GRE Encapsulation and Header Format. 15.

(29) 2.1.4. Specific Problems and Solutions. 在這個段落內將討論一些由 Mobile IP 工作群組額外所發表的 IETF 文件，其用途在解決 Mobile IP 運行上遭遇特殊的網路環境與設定時所造成的問題。以下便仔細探討這些問題的成因與其解決的方法。搭載防假造過濾器的路由器 (Router with Spoofing Filter) 在 2.1.1 中已經提及 Mobile IP 所採用的路由機制可能造成拓樸上錯誤的路由方式。這會發生在行動端送往通訊端的封包上，當行動端漫遊到外地網域時。 Mobile IP 指出行動端必須在它所送出的 IP 封包中將它的家位址放在來源位址欄位內。但是這個家位址不屬於外地網域的網路前置碼。在現今一個自治系統(Autonomous System, AS)的邊界閘道器(路由器)多半有裝配進(Ingress) 出(Egress)過濾器。這些過濾器必須保護網路避免被那些已經被假造 IP 位址的 IP 封包流進或流出這個自治系統。它的運作方式恰好與路由相反。當一個 IP 封包通過這個路由器，路由器將使用反向路徑遞送(Reverse Path Forwarding, RPF)來找出這個來源 IP 位址是否合法。也就是說，如果這個封包所到達的鏈結是其內來源位址所註冊的預設路徑，則此封包將會被遞送。否則，路由器會捨棄這個封包，因為非常有可能來源位址已經被假造。這種防假造過濾器造成了行動端所送的封包可能無法到達通訊端。為了解決這樣的問題，Mobile IP 實作了一個叫做反向通道技術(Reverse Tunneling)的功能，細節可參考 RFC 3024 文件 [13]。反向通道技術不是必要的。外地代理器與家代理器會在它們的代理器公告中告知行動端是否支援這樣的功能。反向通道技術不是在家代理器往轉交位址的方向建立通道，而是由轉交位址往家代理器的方向，圖 2-15 描繪了上述的情形。因此，如當反向通道技術被使用時，雙向的通道會被建立。 82.50.119.117 82.50.119.117. Correspondent Node. 140.113.215.206 140.113.215.206. 140.113.24.68 140.113.24.68. 140.113.215.0/24. 140.113.24.0/24. Tunnel Home Agent. Mobile Node. Mobile Node. Home Network. Foreign Network 140.113.215.207 140.113.215.207. Figure 2 - 15: Reverse Tunneling Routing Scheme 16. Foreign Agent.

(30) 私有網際網路位址環境 (Private IP Address Environment) 為了解決 IP 位址日漸不足的問題，RFC 1918 文件 [7] 中定義了一段私有網際網路位址，這段 IP 位址可作為企業或單位內自行運用的 IP 位址而無須經過向上游申請的手續。當然使用單位必須負責不讓這些私有網際網路位址的路由資訊流到單位外的網路上，也就是說使用這些位址的主機只能和單位內的其它主機連線，外面的網路看不見單位內這些私有網際網路位址的主機。因此這段私有網際網路位址可重覆地被不同單位內部所使用，進而達到節省 IP 位址的目的。當然這樣的使用方式已不符合現今的需求，因此許多的私有區域網路都透過網路位址轉譯器(Network Address Translator, NAT)來連上網際網路。關於網路位址轉譯器的詳細運作方式將在下一節介紹。 Mobile IP 做的一個基本假設是行動端與外地代理器皆可被一個全域可路由的 IP 位址所識別。這個假設當行動端試圖在網路位址轉譯器後端連線時將無法成立。 Mobile IP 靠著藉由 IP 承載 IP 封裝通道將封包從家網域送到行動端或是外地代理器。在網路位址轉譯器後端連線的行動端只能被網路位址轉譯器的公開位址所找到。而 IP 承載 IP 封裝因為沒有包含足夠的資訊，所以無法允許從公共的公開位址到處在網路位址轉譯器後端的行動端或是外地代理器轉交位址唯一的轉譯。特別是當沒有可用的 TCP 或 UDP 埠號供網路位址轉譯器運作。基於這個原因，IP 承載 IP 通道無法通過一個網路位址轉譯器，也就是 Mobile IP 將無法經由網路位址轉譯器來運作。而在另一方面，Mobile IP 的註冊要求與註冊回覆由於是 UDP 的資料封包，所以是可以通過網路位址轉譯器的。當註冊要求通過時，它會使得網路位址轉譯器建立一個位址/埠號的對應，讓註冊回覆得以進到正確的接收端。所以 Mobile IP 需要的是另一個可供選擇的資料封裝機制提供網路位址轉譯器裝置唯一轉譯的方法以及一個註冊的機制來允許這樣的資料封裝機制在適當的時機被建立。 IETF 組織在 RFC 3519 文件中提出了這樣的解決方案，我們將在稍後的 3.2 節中解釋。. Section 2.2. NAT. 在過去的十年內許多 IP 相關的技術引發了某種程度的科技爭論。其中一項就是網路位址轉譯器(Network Address Translator, NAT)。本節中將描述網路位址轉譯器內部的運作，首先在 2.2.1 的部分會介紹網路位址轉譯器被開發的原因，而在稍後的 2.2.2 中將深入瞭解其運作的模式。. 2.2.1. NAT Motivation. 第一份描述網路位址轉譯器的 RFC 文件是由 Kjeld Egevang 與 Paul Francis 於 1994 年所發表的，其編號為 RFC 1631 [4]。網路位址轉譯器的作用背後原始的動機是基於在 1990 年代初期關於對接替 IPv4 協定的努力。以整體的貢獻來說，IPv4 的接替協定是設計出一套協定可以直接地解決 IPv4 位址由於加速地消耗所導致即將發生位址消耗殆盡的問題。雖然 IPv4 有能力定址 44. 17.

(31) 億個裝置，但早在 1992 年就被證實由於全世界朝向部署具備通訊能力的裝置，而 IPv4 卻無法擴展到未來裝置部署的範圍。網路位址轉譯器的目的就是制訂一個機制允許 IP 位址被許多裝置所共享。除此之外，它還預期網路位址轉譯器能以漸進的方式部署在網際網路內而不需造成其它主機或是路由器的改變。原始的 RFC 描寫這種方法能”當其它更複雜與長期研究的解決方案出現前提供暫時性的替代”。所以，如同文件所說，最初網路位址轉譯器的意圖是希望當遠程的解決方案正在被設計之時能夠近程的解決位址耗盡的問題。網路位址轉譯器也希望是未受管理的裝置，對於端對端(Endto-end)的協定是透明的，終端系統與網路位址轉譯器裝置間無須特定的互動。十年後的現在，網路位址轉譯器達到了幾近普遍存在部署於網際網路上的狀態。雖然 IPv6 已經被制訂並開始部署，網路位址轉譯器似乎在網路的園地上成為非常根深蒂固的一部分。. 2.2.2. NAT Operation. 網路位址轉譯器是被放置在資料路徑上的主動單元，通常作為邊界路由器或是區域閘道器的一個作用元件。網路位址轉譯器攔截所有的 IP 封包並可能修改或未修改封包的內容後向前遞送此封包，或是它也可以決定丟棄這個封包。與傳統的路由器或是防火牆本質上的差異在於網路位址轉譯器在遞送封包前可以任意修改 IP 封包的能力。網路位址轉譯器與防火牆相似，但不同於路由器。它有一個”內部”與一個”外部”，並且對攔截的封包採取不同的運作基於封包是由內部往外部或是相反的方向。網路位址轉譯器是 IP 標頭的轉譯器，特別是，它是 IP 位址轉譯器。 IP 標頭包含了來源與目的 IP 位址。如果封包是由內部往外部的方向，網路位址轉譯器將重寫封包標頭中的來源位址。當封包是由外部接收到，目的位址會被重寫。由 RFC 1631 定義的典型網路位址轉譯器將 IP 位址由一個網域對應到另一個。雖然它能被用來在任何兩個網域位址間轉譯，但網路位址轉譯器最主要被用在對應定義在 RFC 1918 中不可繞送的私有位址，如下表所示。. Class A B C. Address Range 10.0.0.0 ... 10.255.255.255 172.16.0.0 ... 172.31.255.255 192.168.0.0 ... 192.168.255.255. Address Mask 10.0.0.0/255.0.0.0 172.16.0.0/255.240.0.0 192.168.0.0/255.255.0.0. Table 2 - 1: Private IP Addresses Table. 這些位址被分配作為不需要外界存取或是對外界服務需要限制存取的私有網路所使用。企業可以免費的使用這些位址來避免去獲得已註冊的公開位址。但是因為私有位址能被許多人，單獨用在其內的網域，因此它們在普通的基礎建設上是不可繞送的。當擁有私有網路位址的主機需要與公開的網路通訊時，網路位址轉譯器就必須存在。這也就是網路位址轉譯器的由來。. 18.