idnits 2.17.1 draft-teoyeow-mip-rat-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 494: '... Extension MUST be included in a...' RFC 2119 keyword, line 564: '... unspecified and MUST be ignored on re...' RFC 2119 keyword, line 586: '...cation Extension MUST be included in a...' RFC 2119 keyword, line 791: '...le node is received, the event MUST be...' RFC 2119 keyword, line 798: '...tration failures MUST be logged. The m...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9386 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'REF 3' on line 286 -- Looks like a reference, but probably isn't: 'REF 4' on line 195 -- Looks like a reference, but probably isn't: 'REF 2' on line 156 -- Looks like a reference, but probably isn't: 'REF 1' on line 782 == Unused Reference: '2' is defined on line 818, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 822, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 826, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '9') Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. T. Teo 3 INTERNET DRAFT S. W. Yeow 4 National University of Singapore 5 August 1998 7 Reverse Network Address Translators (RAT) 8 10 Status of This Memo 12 This document is a submission to the MobileIP Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 to the mobile-ip@smallworks.com mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (North Europe), 31 ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 32 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 Mobile IP faces difficulties in deployment as all mobile nodes need to 37 support the protocol. While the implementation and deployment issues 38 of the Mobile IP home agents do not affect the mobile end-users, the 39 users are more constrained to the operating systems which support 40 MobileIP on their mobile nodes. 42 This document describes an alternative protocol that attempts to 43 solve the deployment problem. It provides IP reachability for mobile 44 users through the use of Reverse Network Address Translators (RAT). 45 This technique leverages on the popularity of Network Address 46 Translators (NAT) and NAPTs to provide transparent mobility to end 47 hosts.The protocol's requirements for the mobile node are thus minimal. 48 Moreover, the RAT protocol is interoperable with the MobileIP base 49 protocol. 51 1. Introduction 53 IP version 4 datagram routing generally depends on the destination 54 host's IP address to uniquely identify the host point of attachment 55 in the Internet. This implies a host has to be on the network 56 indicated by its IP address - the home address in Mobile IP (MIP) 57 terminology - to receive packets destined to it. 59 This document proposes protocol enhancements to NAT which allow other 60 hosts to initiate communication using a mobile node's home address 61 when the latter changes location. 63 This document does not attempt to describe address translations at a 64 RAT device above the network level. RAT only deals with network 65 address translation of the IP header. Network Address Port 66 Translation (NAPT) and Application Level Gateways (ALGs) can continue 67 to operate on top of RAT. 69 When a mobile node moves from its home network, by reverse network 70 address translation, datagrams destined for its home address can be 71 transparently routed to its new location. 73 The mobile node will always use a topologically correct IP address as 74 its source address. This address will be the home address when the 75 mobile node is in its home network. The address will be a care-of 76 address assigned by an external mechanism when the mobile node is in 77 a foreign network. 79 Reverse network address translation is only required when the mobile 80 node is not at home and the network sessions are initiated by the 81 correspondent nodes, e.g. when the mobile node is an application 82 server. For all other situations, the mobile node will communicate 83 directly with its correspondent nodes, without the overhead incurred 84 by RAT, i.e. the correspondent nodes respond to the mobile node using 85 the latter's topologically correct address. 87 1.1 Goals 89 The main motivation for RAT is to facilitate deployment. Common 90 network technologies are used where possible to reduce implementation 91 effort. Until Mobile IP (MIP) is widely supported on all operating 92 platforms for mobile users and MIP home agent's functions are 93 available on routers, IP mobility support on the Internet will be 94 limited. 96 Since NAT routers are already widely deployed and implementations 97 with twice NAT [REF 3] are available, to provide RAT capability on 98 current NAT [REF 4] devices require minimal enhancements. Networks 99 with NAT installations will be mobile capable by migrating to RAT. By 100 depending on currently available network applications for 101 registration, little effort is needed on the user's part to gain the 102 benefit of mobility. 104 By network address translations, RAT provides transparent mobility to 105 end hosts. No enhancements to a mobile node's transport and lower 106 network layers are necessary. 108 The application protocol employed in the registration process is 109 flexible and independent of RAT's base protocol. However, for 110 interoperability reasons, the control messages between a registration 111 server and a RAT device must be followed. 113 1.2 Applicability 115 The protocol does not attempt to maintain transport and higher-layer 116 connections when a node changes location. The main function of RAT is 117 to allow correspondent nodes to locate a mobile node by its 118 permanently assigned home address. 120 1.3 Deployment Issues 122 In a basic setup, to support RAT, a network needs a registration 123 server and a RAT device for each physically partitioned subnet. The 124 mobile node does not require foreign networks to support RAT to have 125 mobility support. However, the node must be able to acquire a 126 topologically correct IP care-of address via any available external 127 mechanism in the foreign location. 129 1.4 Protocol Requirements 131 The mobile node must be able to access at least one of its 132 registration servers when in a foreign location. 134 The RAT device must be able to deliver datagrams to the mobile node's 135 foreign location. 137 All messages used to inform the registration server as to the mobile 138 node current location must be authenticated to protect against remote 139 redirection attacks. 141 1.5 End Host Accessibility 143 All correspondent nodes will be able to reach the mobile node if its 144 currently assigned IP address is reachable by the RAT device using 145 the appropriate routable addresses. 147 Correspondent nodes previously accessible by a mobile node at home 148 may not be reachable when the mobile node is in a foreign location. 149 This is because the correspondent node's access control list or 150 network firewall may deny traffic originating from the mobile node's 151 current location. This is not a design flaw since the existing 152 security policies should not be circumvented for mobility support. 154 Another reason why a mobile node cannot reach certain correspondent 155 nodes is when the latter are in a network using private IP addresses 156 [REF 2] and the mobile node has moved outside the private network, or 157 when the mobile node has moved into a private network without NAT 158 support. The protocol should not allow a mobile node to reach these 159 correspondent nodes unless the security policies permits. 161 Private correspondent nodes can still reach a mobile node outside the 162 internal network using RAT. The RAT device may deny the forwarding of 163 such datagrams for security reasons and send an ICMP Host-Unreachable 164 error to the correspondent node. 166 1.6 NAT and RAT differences 168 Network Address Translation (NAT) is typically used when a network's 169 internal IP addresses cannot be used externally. NAT can connect 170 separate routing realms with different addressing schemes. It does 171 that by translating the network address of datagrams to the 172 appropriate routable address in the corresponding routing space. 173 Therefore NAT is used when the end hosts are in different routing 174 realms. The NAT device must be assigned an address in each of the 175 routing realm it connects. 177 The purpose of Reverse Network Address Translation (RAT) is 178 different. RAT is used even when the end hosts are in the same 179 routing space to forward datagrams destined to the mobile node's home 180 address to the latter's care-of address. The RAT device only needs to 181 be assigned one address if all end hosts are in the same routing 182 space. 184 Reverse Network Address Translation (RAT) does twice Network Address 185 Translation [REF 3] for datagram delivery. In twice NAT, both the 186 source and destination addresses are translated. The current reason 187 for twice NAT is to connect end hosts that use overlapping address 188 space in their home network. A unique intermediate address space is 189 used to connect the end hosts i.e. the RAT device becomes the virtual 190 sender/receiver of the mobile/correspondent nodes. 192 NAT is always needed for communicating hosts in separate routing 193 realms regardless of the session direction [REF 3]. RAT is needed 194 only when the session is intiated by the correspondent nodes. In 195 traditional NAT [REF 4], translation is initiated by the client nodes 196 which the NAT device services. RAT translation is reverse initiated 197 by the correspondent nodes and by not the mobile client nodes which 198 the RAT device services. 200 1.7 Mobile IP and RAT comparison 202 The Network Address Translator (NAT) and NAPT have become popular 203 because of easy deployment. They require no modifications to the 204 communicating hosts. Mobile IP however faces difficulties in 205 deployment as all mobile nodes need to support the protocol. While 206 implementation and deployment of Mobile IP home agents need not be 207 concerned with the operating system, mobile users are constrained to 208 operating systems which supports Mobile IP. Network adminstration for 209 Mobile IP's security authentication and key allocation also requires 210 additional configuration tools for the novice user. 212 The base protocol of Mobile IP does not support communication across 213 different routing realms e.g. between private and public nodes. If 214 such mobility support is desired, Mobile IP extension for Private 215 Internets Support [8] or Firewall Support for Mobile IP [9] is 216 needed. NAT's main function is to allow communication between 217 different routing realms. If the current NAT installation already 218 support such communication for sessions initiated in any routing 219 realm, RAT can provide the mobility support without additional 220 enhancements. 222 Mobile IP uses IP tunneling to deliver datagrams to a mobile node's 223 care-of address. This allows a mobile node to bypass traditional 224 firewalls that only filter packets based on the IP tunnel header. 225 RAT uses twice NAT/NAPT to deliver datagrams to a mobile node's 226 care-of address. Certain applications which embed the end hosts' IP 227 addresses in the data payload will not function with NAT/NAPT if 228 there are no application layer gateways available to support them. 230 Mobile IP specifies the registration message formats and semantics 231 for mobile nodes. RAT uses common application protocols supported on 232 any network operating systems. The delivery mechanism - twice 233 NAT/NAPT - is explicitly separated from the registration mechanism in 234 RAT. 236 RAT provides limited mobility in comparison to Mobile IP. It does not 237 attempt to maintain connection orientated sessions while the mobile 238 node moves across multiple networks. 240 Where the abovementioned limited mobility and application support is 241 sufficient, RAT is much easier as a deployment solution. 243 In Mobile IP, there are 2 main purposes for a mobile node to have a 244 fixed IP address - the home IP address : 246 1. To enable all correspondent nodes to identify the mobile node with 247 a fixed IP address that is unchanged regardless of location. 249 2. To retain connection orientated transport protocols, e.g. TCP 250 connections, while the mobile node moves across networks. 252 The intended function of RAT is to achieve the first purpose. It is 253 typically unnecessary for the mobile node in a foreign location to 254 use its home IP address as the source IP address when originating a 255 datagram. 257 Such an approach as defined in MobileIP has two disadvantages : 259 1. Datagrams originating from the correspondent node will generally 260 need to be routed to the mobile node's home network before they 261 are tunnelled to the mobile node care-of address. 263 2. If Ingress filtering is deployed at the mobile node's current 264 foreign location to filter datagrams with topologically incorrect 265 source IP address, bidirectional tunneling is required to bypass 266 the Ingress filter. 268 Both of the above situations may result in a longer routing path 269 between the sender and receiver. 271 In RAT, for a correspondent node initiated session, the end hosts' 272 routing path is similiar to bidirectional tunneling in Mobile IP. 273 This will form a dog-legged route, from the mobile node to RAT device 274 to correspondent node and vice versa. 276 For communication initiated by the mobile node, since both the end 277 hosts' addresses used are topologically correct, standard IP routing 278 is sufficient and RAT will not be involved. However, communication 279 will fail in situations where the home IP address is necessary e.g. 280 firewalls. 282 2. Terminology 284 The document adopts all the terminology defined in "IP Mobility 285 Support" [REF 1] and "IP Network Address Translator Terminology and 286 Considerations" [REF 3]. 288 Three new entities are introduced : 290 1. Zero Implementation Mobile Node (0MN) 292 Zero Implementation Mobile Node (0MN) identifies a mobile host that 293 supports RAT. This is to differentiate the former from the same term 294 used in Mobile IP. 296 2. Registration Server (RS) 298 A registration server is generally located in the mobile node's home 299 domain. A 0MN must inform the RS of its new location in a foreign 300 network before it can receive datagrams destined for its home 301 address. The RS needs to be reachable from the mobile node's current 302 location using the available routing mechanisms for the registration 303 process to be successful. 305 The registration server will interact with a RAT device to set up the 306 reverse translation table. The table binds a mobile node's home IP 307 address with its care-of address and the binding's lifetime. 309 The discovery of a registration server is not specified by the 310 protocol and is dependent on the application protocol used in the 311 registration process. For example if the registration server uses 312 HTTPS for registration, a mobile user may identify the RS by a URL 313 address. For the simplest configuration, the RS address can be 314 statically configured. 316 3. Reverse Network Address Translator (RAT) 318 The Reverse Network Address Translator maintains a 0MN's home IP 319 address association with a care-of address and the binding's 320 lifetime. It uses twice NAT to route datagrams from a 0MN's home 321 address to care-of address. 323 The RAT device is generally directly connected to the 0MN's home 324 network in order to receive datagrams destined for the latter e.g. by 325 proxy ARP. The requirement is unnecessary if the RAT device can 326 interoperate with the Mobile IP's home agent entity [REF 1]. The home 327 agent can then tunnel datagrams destined for the 0MN to the RAT 328 device for final delivery to the 0MN's care-of address. 330 It is not neccessary for a 0MN to know the identity of the RAT device 331 for the protocol to work. For security reasons, only the RS should 332 know the RAT devices available in a network. 334 3. Registration Application Protocol Selection 336 The application protocol used by a mobile node to register its 337 current care-of address with a registration server is independent of 338 the protocol. However for security reasons the application protocol 339 must fulfill the following criteria : 341 1. A mechanism to validate both the mobile node/user identity and its 342 current location. 344 A registration server must never assume the source IP address of a 345 registration request is the care-of address of the mobile node. 346 Information disclosure could provide the means of hijacking a 347 mobile node traffic. Therefore it is recommended that the mobile 348 node's care-of address be encrypted. Using a user-centred 349 authentication scheme, the mobile node home IP address need not be 350 sent during the registration process if the registration server 351 maintains a mobile user to mobile node home address association. 353 2. A mechanism to confirm the mobile node is still at its current 354 registered location. 356 The mobile node will need to renew its care-of address by 357 re-registration or some similar mechanism, within an appropriate 358 lifetime. This is to avoid forwarding datagrams to an old location 359 the mobile node has vacated. This renewal request should be 360 time-stamped etc to avoid possible replay attacks. 362 For easy deployment of RAT as a mobility solution, the application 363 protocol used should be widely supported on all operating platforms. 364 A good example of an application protocol that meets the above 365 security and availability requirements is the Secure Hypertext 366 Transfer Protocol (HTTPS), which is HTTP over a Secure Socket Layer 367 (SSL). 369 A mobile user will only need a World Wide Web (WWW) browser to access 370 a WWW server on the registration server. Java applets may be 371 downloaded from the registration server to request user 372 authentication. With verification of user identity, the applet can 373 then transmit time-stamped "keep alive" beacons back to the RS to 374 confirm the 0MN location. The messages sent can be encrypted/ 375 authenticated using a private key the mobile user provided. The 376 method of encryption/authentication need not be known to any entity 377 except the registration server. 379 The specifics of the registration process are beyond the scope of 380 this document. 382 4. Acquiring Care-Of Address 384 When a 0MN is in a foreign network and desire mobility support, it 385 must acquire a topologically correct IP address in the network. Any 386 available external mechanism supported by the mobile node can be used 387 to acquire a care-of address. Popular protocols available are the 388 Dynamic Host Configuration Protocol (DHCP) or the Point to Point 389 Protocol (PPP). 391 5. Control Messages 393 Control messages are used to exchange information between the 394 registration server and RAT device. It is not recommended that both 395 entities reside on the same machine for the following reasons : 397 1. The application protocol used for registration may change with the 398 introduction of newer technology but the RAT mechanism will remain 399 the same. 401 2. Address translations incur large overhead in memory and 402 computation [refer to Section 9] and dedicated hardware may be 403 needed. Administration and installation of myriad feasible 404 application protocols on dedicate hardware is not viable. 406 3. Failure of the registration server or RAT device will deny 407 mobility services. Introducing backup registration servers and 408 alternative RAT devices can increase reliability and distribute 409 load. 411 The control messages are sent with UDP [5] using the well-known port 412 number 434 allocated to Mobile IP. New authentication extensions are 413 defined to indicate RAT operation. The default authentication 414 algorithm uses keyed-MD5 [6] in "prefix+suffix" mode to compute a 415 128-bit "message digest" of the control message. 417 5.1 Reverse Translation Binding (RTB) Request 419 A registration server sends a Reverse Translation Binding Request 420 (RTBR) to a RAT device to setup the reverse translation table - 0MN's 421 home address, care-of address, binding's lifetime. 423 The Mobile IP registration request format is used. 425 The format is as follows : 427 IP fields: 429 SA: Typically the interface address from which the registration 430 server sends the message. 432 DA: Typically that of the RAT device. 434 UDP fields: 436 Source Port: variable 438 Destination Port: 434 440 The UDP header is followed by the RAT fields shown below: 442 0 1 2 3 443 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Type |0|B|D| 0 | Lifetime | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Home Address | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Registration Server | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Care-of Address | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | | 454 + Identification + 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Extensions ... 458 +-+-+-+-+-+-+-+- 460 Type 1 (Registration Request) 462 B Broadcast datagrams. If the 'B' bit is set, the 463 registration server requests that the RAT device 464 forwards any broadcast datagrams that the 0MN receives on 465 the home network. 467 D Decapsulation by RAT device. If the `D` bit is set, the 468 RAT device will decapsulate datagrams which are tunneled 469 from a Mobile IP's home agent [Refer to Section 8]. 471 Lifetime 472 The number of seconds remaining before the registration 473 is considered expired. A value of zero indicates a 474 request for deregistration. A value of 0xffff indicates 475 infinity. 477 Home Address 478 The IP address of the 0MN. 480 Registration Server 481 The IP address of the 0MN's registration server. 483 Care-of Address 484 The IP address of the 0MN current location. 486 Identification 487 A 64-bit number, constructed by the registration server 488 node, used for matching RTB with RTB Replies, and for 489 protecting against replay attacks of RTB messages. 491 Extensions 492 The fixed portion of the RTB Request is followed by one 493 or more of the Extensions. The RAT-Server Authentication 494 Extension MUST be included in all RTB Requests. 496 5.2 Reverse Translation UnBinding (RTU) Request 498 When a 0MN is no longer at its registered care-of address, i.e. no 499 "keep alive" beacons are sent by the 0MN to the registration server 500 or its reverse translation binding's lifetime expires, the 501 registration server must send a Reverse Translation UnBinding Request 502 to the RAT device to remove the 0MN entry in the reverse translation 503 table. 505 The format of the RTU request is the same as the RTB request except 506 the lifetime field is 0. 508 5.3 RAT Control Message Reply 510 A RAT device returns a Control Reply message to a registration server 511 which has sent a RTB or RTU message. 513 The Mobile IP registration reply format is used. 515 The format of the extension is as follows : 517 IP fields: 519 SA: Typically copied from the destination address of the RTB or 520 RTU Request to which the RAT device is replying. 522 DA: Copied from the source address of the RTB or RTU request to 523 which the agent is replying 525 UDP fields: 527 Source Port: 529 Destination Port: Copied from the source port of the 530 corresponding RTB or RTU Request 532 The UDP header is followed by the RAT fields shown below: 534 0 1 2 3 535 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Type | Code | Lifetime | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Home Address | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Registration Server | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | | 544 + Identification + 545 | | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Extensions ... 548 +-+-+-+-+-+-+-+- 550 Type 3 (Registration Reply) 552 Code A value indicating the result of the Registration 553 Request. See below for a list of currently defined Code 554 values. 556 Lifetime 557 If the Code field indicates that the registration was 558 accepted, the Lifetime field is set to the number of 559 seconds remaining before the registration is considered 560 expired. A value of zero indicates that the mobile node 561 has been deregistered. A value of 0xffff indicates 562 infinity. If the Code field indicates that the 563 registration was denied, the contents of the Lifetime 564 field are unspecified and MUST be ignored on reception. 566 Home Address 567 The IP address of the 0MN. 569 Home Agent 570 The IP address of the 0MN's registration server. 572 Identification 573 A 64-bit number used for matching RTB or RTU Requests 574 with RTB or RTU Replies, and for protecting against 575 replay attacks of RTB or RTU messages. The value is 576 based on the Identification field from the RTB pr RTU 577 Request message from the mobile node, and on the style of 578 replay protection used in the security context between 579 the registration server and its RAT device (defined by 580 the security association between them, and SPI value in 581 the Server-RAT Authentication Extension). 583 Extensions 584 The fixed portion of the RTB or RTU Reply is followed 585 by one or more of the Extensions. The RAT-Server 586 Authentication Extension MUST be included in all Control 587 Replies returned by the RAT device. 589 The following values are defined for use within the Code field. RTB 590 or RTU successful: 592 0 registration accepted 594 RTB or RTU unsuccessful: 596 64 reason unspecified 597 65 administratively prohibited 598 66 insufficient resources 599 68 registration server failed authentication 600 69 requested Lifetime too long 601 70 poorly formed Request 602 128 reason unspecified 603 129 administratively prohibited 604 130 insufficient resources 605 133 registration Identification mismatch 606 134 poorly formed Request 607 136 unknown registration server address 609 5.4 RAT-Server Authentication Extension 611 A RAT-Server Authentication extension type is defined to indicate 612 support for RAT operation. 614 The format of the extension is as follows : 616 0 1 2 3 617 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Type | Length | SPI .... 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 ... SPI (cont.) | Authenticator ... 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 Type 36 626 Length 4 plus the number of bytes in the Authenticator. 628 SPI Security Parameter Index (4 bytes). An opaque 629 identifier. 631 Authenticator (variable length) 633 If the extension is missing in a RTB or RTU request and the RAT 634 device is also a Mobile IP home agent entity, it must process the 635 message as a registration request as specified in Mobile IP. 637 6. Reverse Address Translation 639 On successful registration with a registration server, a 0MN is 640 associated with the tuple . For 641 any session initiated by a correspondent node, all requests and 642 reponse must be routed via the same RAT device. 644 Any datagram with a destination address that is a registered 0MN's 645 home address in the reverse translation table must be reverse address 646 translated. Any reply from the registered 0MN to the RAT device must 647 be similarly translated. 649 The following example illustrates the operation of a RAT device at 650 the network level. Network Address Port Translations and Application 651 Layer Gateways' operations (if any) are not illustrated. 653 Correspondent Node Address: 137.0.0.10 654 Home Network: 138.0.0.0/24 655 0MN home address: 138.0.0.10 656 0MN care-of address: 139.0.0.10 657 RAT device address: 138.0.0.1 659 Home Network 660 DA: 138.0.0.10 +-------------------------- 661 +-------------+SA: 137.0.0.10 | +------+ 662 |correspondent|---------------|->| RAT | 663 | node |<-----------------|device| 664 +-------------+DA: 137.0.0.10 | +------+ 665 SA: 138.0.0.10 +---|---^------------------ 666 | | 667 | | 668 DA: 139.0.0.10| |DA: 138.0.0.1 669 SA: 138.0.0.1 | |SA: 139.0.0.10 670 v | 671 +---+ 672 |0MN| 673 +---+ 675 7. ICMP Error Translation 676 When a RAT device receives an ICMP Destination-Unreachable error 677 message for datagrams destined to a care-of address in the reverse 678 address translation table, the error message should be translated as 679 follows : 681 IP fields: 683 SA: RAT device's outgoing interface address to correspond node 684 DA: correspondent node address that initiated the session 686 ICMP field: 688 Type: 3 690 If the ICMP code indicates network unreachable, it should be replaced 691 by the corresponding host unreachable number. The IP header embedded 692 within the ICMP payload must be similarly modified. 694 8. Interoperation with MobileIP 696 The Registration Server and RAT device may interoperate with Mobile 697 IP home agent(s) deployed on the mobile nodes' home network. In such 698 an approach, it is not necessary for the RAT device to be directly 699 connected to the network(s) of the mobile nodes its services. The RS 700 must have the mobile-home security associations [1] of the mobile 701 nodes and the RAT device must support IP tunnel decapsulation [7]. 703 Interoperation will also allow a user whose home network deploys 704 Mobile IP home agents but does not have Mobile IP mobile node 705 implementations on the preferred operating platform to have mobility 706 support. 708 In such a scenario, the RS on receiving a valid registration request 709 from a mobile node must send a Mobile IP registration request [1] to 710 the home agent on behalf of the 0MN. The RS must be able to generate 711 the Mobile-Home Authentication extension. The only difference in the 712 message format is the care-of address is replaced by a RAT device IP 713 address. On receiving a successful registration reply from the home 714 agent, the RS must send a RTB request with the `D` - decapsulation - 715 bit set to the RAT device. The RS will need to renew the mobility 716 binding at the home agent as specified by Mobile IP. 718 Datagrams destined for the 0MN's home address will now be IP 719 encapsulated and tunneled to the RAT device. The RAT device will 720 decapsulate the packet and forward the datagram to the mobile node 721 actual location via twice NAT. The RS device should send a 722 deregistration request when the 0MN's entry in its reverse address 723 translation table is no longer valid. 725 For a RAT device that also operates as a NAT router, the mechanism to 726 choose whether to decapsulate or translate an IP encapsulated 727 datagram is outside the scope of this document. A possible solution 728 is to reserve an IP address on the RAT device that must decapsulate 729 incoming tunneled packets. The IP address is then used to substitute 730 all care-of addresses in Mobile IP registration messages. 732 The diagram illustrates datagram delivery with Mobile IP and RAT 733 interoperation for sessions initiated by correspondent nodes. 735 2) Datagram is intercepted 3) Datagram is 736 by home agent and detunneled, 737 is tunneled to the translated by RAT 738 care-of address. device and delivered 739 to 0MN by standard IP 740 routing 741 +-----+ +------+ +---+ 742 |home | =======> | RAT | ------> |0MN| 743 |agent| |device| <------ +---+ 744 +-----+ +------+ 745 1) Datagram to ^ / 746 mobile node | / 4) Datagram is sent back to RAT 747 arrives on | / device 748 home network | / 749 via standard | |_ 5) Datagram is translated by RAT 750 IP routing. +-------------+ device and delivered to 751 |correspondent| correspondent node via 752 | node | standard IP routing. 753 +-------------+ 755 9. Scalability Issues 757 The overhead of maintaining address tables and performing address 758 translations is computationally intensive. Each data packet is 759 subjected to RAT lookup and modifications. This implies the RAT 760 device is a possible bottleneck and point of failure. If there are 761 alternative RAT devices, recovery of the reverse translation table 762 during a RAT device failure is possible with the information stored 763 in the registration server. 765 10. RAT Limitations 767 For any sessions that requires RAT when a mobile node is not at home, 768 applications or security mechanisms that fail with NAT/NAPT with no 769 available specific application layer gateway (ALG), will similarly 770 fail with RAT. 772 RAT is subjected to additional limitations listed in [REF 1] when 773 address translations are necessary. 775 11. Current Implementation 777 A prototype implementation of RAT by S. W. Yeow is now undergoing 778 testing. 780 12. Security Considerations 782 The security considerations described in [REF 1] for all variations 783 of NATs are applicable to RAT when address translations are 784 necessary. 786 A security log must be maintained at the registration server. Each 787 registration request should 788 be recorded. 790 If simultaneous valid registration requests with different care-of 791 addresses from the same mobile node is received, the event MUST be 792 logged. The registration server must discard all future registration 793 requests from the same mobile node. A registration failure message 794 should be sent to the requested care-of address if the application 795 protocol supports error handling. The format of the message will be 796 dependent on the application protocol used. 798 All registration failures MUST be logged. The mobile user should be 799 informed the time of the most recent successful/failed registration 800 for each new registration attempt if possible. 802 Acknowledgements 804 Many thanks to Dr Y. C. Tay at the National University of Singapore 805 for his valuable help in reviewing this document. 807 Special thanks to Rhandeev Singh at the National University of 808 Singapore for his contribution to the protocol implementation. 810 RAT research and development is funded in part by the National 811 University of Singapore ARF grant RP960683. 813 References 815 [1] Perkins, C., Editor, "IP Mobility Support", RFC 2002, October 816 1996 818 [2] Rekhter, Y., Moskowitz, B. Karrenberg, D., G. de Groot, and 819 Lear, E. "Address Allocation for Private Internets", RFC 1918, 820 February 1996 822 [3] P. Srisuresh, M. Holdrege, "IP Network Address Translator (NAT) 823 Terminology and Considerations", 824 - work in progress, July 1998 826 [4] P. Srisuresh, K. Egevang, "Traditional IP Network Address 827 Translator (Traditional NAT)", 828 - work in progress, July 1998 830 [5] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980 832 [6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 833 1992 835 [7] Perkins, C., "IP Encapsulation within IP", RFC 2003, May 1996 837 [8] W. T. Teo, Y. Li, "Mobile IP extension for Private Internets 838 Support", - work in progress, 839 March 1998 841 [9] Montenegro, G., Gupta, V., "Sun's SKIP Firewall Traversal for 842 Mobile IP", RFC 2356, June 1998 844 Author's Address 846 W. T. Teo 847 National University of Singapore 848 School of Computing 849 Lower Kent Ridge Cresent 850 Singapore 119260 852 EMail: teoweetu@comp.nus.edu.sg 854 Phone: (65) - 282 0005 856 S. W. Yeow 857 National University of Singapore 858 School of Computing 859 Lower Kent Ridge Cresent 860 Singapore 119260 862 EMail: yeowshin@comp.nus.edu.sg 864 Phone: (65) - 257 3832