idnits 2.17.1 draft-liyunzhou-mobileip-ppm-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-25) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 404: '...ed by the server, which MAY be smaller...' RFC 2119 keyword, line 450: '... MUST be ignored on rece...' RFC 2119 keyword, line 581: '... MUST have this bit set when i...' RFC 2119 keyword, line 651: '... This extension MAY be present in Pro...' RFC 2119 keyword, line 674: '... This extension MUST be present in Ag...' (84 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1065 has weird spacing: '...rack of mobil...' -- 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 (5 November 1996) is 10033 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) == Unused Reference: '3' is defined on line 1086, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1094, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1098, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1103, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1105, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) -- Possible downref: Normative reference to a draft: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. '3') == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-04 -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 1700 (ref. '10') (Obsoleted by RFC 3232) Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Yunzhou Li 2 INTERNET DRAFT National University 3 of Singapore 4 5 November 1996 6 Proximity Proxies for Mobile Nodes and Mobility Agents (PPM) 7 draft-liyunzhou-mobileip-ppm-00.txt 9 Status of This Memo 11 This document is a submission to the Mobile-IP Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the mobile-ip@smallworks.com mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at 24 any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 29 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Abstract 35 This document aims to explore an approach for the interoperability 36 testing of Mobile IP implementations across the Internet. It proposes 37 client/server proximity proxies, two intermediate entities between 38 the mobile node and the mobility agent. This model can be used to 39 solve the problem addressed in the hierarchical foreign agents model. 40 The document proposes to build a tunnel between proximity proxies 41 using Tunnel Request and Tunnel Reply messages, and enable routing 42 policies to the tunnel by using Proxy Update message and adding a bit 43 in Agent Advertisement message. 45 Contents 47 Status of This Memo i 49 Abstract i 51 1. Introduction 1 53 2. PPM Overview 2 54 2.1. Client/Server Proxy . . . . . . . . . . . . . . . . . . . 2 55 2.2. Client/Server Tunnel . . . . . . . . . . . .. . . . . . . 3 56 2.3. Tunnel Requst and Tunnel Reply Messages . . . . . . . . . 3 57 2.4. Agent Solicitation Message . . . . . . . . . . . . . . . 3 58 2.5. Agent Advertisement Message . . . . . . . . . . . . . . 4 59 2.6. Proxy Update Message . . . . . . . . . . . . . . . . . . 5 61 3. PPM Message Formats 5 62 3.1. Tunnel Request Message . . . . . . . . . . . . . . . . . 6 63 3.2. Tunnel Reply Message . . . . . . . . . . . . . . . . . . 7 64 3.3. Proxy Update Message . . . . . . . . . . . . . . . . . . 8 65 3.4. Agent Solicitation Message . . . . . . . . . . . . . . . 9 66 3.5. Agent Advertisement Message . . . . . . . . . . . . . . . 10 68 4. PPM Extension Formats 11 69 4.1. Server Proxy Extension . . . . . . . . . . . . . . . . . 11 70 4.2. Client Proxy Extension . . . . . . . . . . . . . . . . . 11 71 4.3. Mobile-Cleint Authentication Extension . . . . . . . . . 12 72 4.4. Client-Server Authentication Extension . . . . . . . . . 12 73 4.5. Server-Agent Authentication Extension . . . . . . . . . . 13 75 5. Mobile Node Considerations 14 76 5.1. Sending Agent Solicitation . . . . . . . . . . . . . . . 14 77 5.2. Receiving Agent Advertisement . . . . . . . . . . . . . . 14 78 5.3. Handover . . . . . . . . . . . . . . . . . . . . . . . . 14 79 5.4. Sending Proxy Update . . . . . . . . . . . . . . . . . . 15 81 6. Client Proxy Considerations 16 82 6.1. Sending Tunnel Request . . . . . . . . . . . . . . . . . 16 83 6.2. Receiving Tunnel Reply . . . . . . . . . . . . . . . . . 16 84 6.3. Receiving Agent Solicitation . . . . . . . . . . . . . . 17 85 6.4. Receiving Agent Advertisement . . . . . . . . . . . . . . 17 86 6.5. Receiving Proxy Update . . . . . . . . . . . . . . . . . 18 88 7. Server Proxy Consideration 19 89 7.1. Receiving Tunnel Request . . . . . . . . . . . . . . . . 19 90 7.2. Receiving Agent Solicitation . . . . . . . . . . . . . . 19 91 7.3. Receiving Agent Advertisement . . . . . . . . . . . . . . 20 92 7.4. Receiving Proxy Update . . . . . . . . . . . . . . . . . 20 94 8. Agent Considerations 21 95 8.1. Receiving Agent Solicitation . . . . . . . . . . . . . . 21 96 8.2. Receiving Agent Advertisement . . . . . . . . . . . . . . 21 97 8.3. Receiving Proxy Update . . . . . . . . . . . . . . . . . 21 99 9. Security Considerations 21 101 References 22 102 Author's Address 23 104 1. Introduction 106 The mobile IP base protocol [1] allows mobile nodes to move from one 107 point of physical attachment within the Internet to another. Under 108 this physical attachment, it is difficult to test interoperability 109 of a few Mobile-IP softwares over the Internet. For example, a mobile 110 node running one Mobile-IP software is not able to connect to a 111 foreign agent running another Mobile-IP software. Furthermore, a 112 mobile node is not able to switch, over the Internet, from a subnet 113 at one remote site to a subnet at another remote site. 115 The second problem to be addressed here is what the hierarchical 116 foreign agents model [2] discloses and has solved. That is, each time 117 the mobile node moves, a Registration Request message has to be 118 approved by the mobile node's Home Agent. In cases where the home 119 agent is far away, it may become too expensive or even impossible to 120 complete these frequent registrations. 122 This document proposes Proximity Proxies for Mobile Nodes and 123 Mobility Agents (PPM), as an extension to the base protocol, in 124 anticipation to solve these two problems. Under the base protocol, a 125 mobile node can change its physical attachment to various links while 126 maintaining its Internet connection. The PPM model provides a tunnel 127 attachment mechanism by introducing pairs of proximity proxies, 128 intermediate entities between mobile nodes and mobility agents. 130 The proximity proxies are built on a client-server model. A client 131 proxy has a physical attachment to and serves mobile nodes, and a 132 server proxy has a physical attachment to and serves mobility agents. 133 A mobile node is said to have a tunnel attachment to a mobility agent 134 if, there is a tunnel between the client and the server, and the 135 client and the server respectively act as proximity proxies to the 136 agent and the mobile node. By proximity proxies, we mean they have 137 proximity function not necessarily using Proxy ARP. Thus the server 138 will be able to attract packets from the agent and tunnel them to the 139 mobile node via the client. In the reverse direction, the client will 140 be able to attract packets from the mobile node and tunnel them to 141 the agent via the server. 143 Under this model, Mobile-IP tests over the Internet become feasible. 144 Each mobile node can be constantly connected to a client. The client 145 can frequently request to switch its tunnel from a server in a remote 146 site to that in another remote site. Thus a mobile node can change 147 its tunnel attachment from one remote agent to another. This model is 148 also able to assist a mobile node in mobility diagnostic. Before a 149 mobile node departs from its home subnet, it can have a client in 150 control and diagnose whether the Internet connection to its 151 destination will be broken or not. 153 Under this model, the second problem can be solved by properly 154 deploying servers and clients. For example, a foreign agent and a 155 server proxy can be deployed in an autonomous system (AS), but more 156 clients can be deployed within the AS. The clients maintains constant 157 tunnels with the server. A mobile node moves around in the AS but is 158 always attached to the agent over a tunnel. Thus no mobile node 159 necessarily re-registers a new binding or registers simultaneous 160 bindings while moving within the AS. Later the document demonstrates 161 that both the agent and the server are able to keep track of mobile 162 nodes and thus act as exchangers in this "switching network". 164 Tunneling methods can be found in [4] and [5]. The document also 165 allows to use other methods to build a tunnel, especially provided in 166 a heterogeneous network. To synchronize bi-directional tunnel between 167 client proxy and server proxy, a client is allowed to send a Tunnel 168 Request message to the server, and the server responds with a Tunnel 169 Reply message. 171 To get a client to be a proximity proxy to a mobility agent, the 172 document requires the server to tunnel Agent Advertisement messages 173 to the client. To get a server to be a proximity proxy to a mobile 174 node, the mobile node is required to address Proxy Update messages to 175 the server via a client. Proxy Update messages can be used by the 176 mobility agent and the server to keep track of the mobile node. 178 To indicate an intent to receive Proxy Update or request more 179 information, the document defines a P-bit in Agent Solicitation 180 message and Agent Advertisement message, and allows to include Server 181 Proxy extension and Client Proxy extension in Agent Advertisement 182 messages and Proxy Update messages. 184 2. PPM Overview 186 2.1. Client/Server Proxy 188 The PPM model provides two new entities, client proxy and server 189 proxy. These two entities are intermediate proximity proxies between 190 mobile node and mobility agent. 192 A client proxy, in short, client, is an Internet node that is on a 193 link, on which mobile nodes may visit. It is called "client" in that 194 it may request a server to build a tunnel towards itself. The client 195 may work as a proximity proxy to a mobility agent without necessarily 196 using proxy ARP. The client should enable a routing policy so that 197 packets for the agent can be routed to the tunnel. 199 A server proxy, in short, server, is an Internet node on a link, on 200 which one or more mobility agents reside. It is called "server" in 201 that it can serve to build a tunnel towards a client upon its request. 202 The server may work as a proximity proxy to a mobile node without 203 necessarily using proxy ARP. The server should enable a routing 204 policy so that packets for the mobile node can be routed to the 205 tunnel. 207 2.2. Client/Server Tunnel 209 A tunnel between a client and a server can be built using methods in 210 [4] and [5], or other methods. Hereafter, it is assumed that a method 211 in [4] or [5] is used, and thus the tunnel could be bi-directional. 213 The bi-directional tunnel should be built simultaneously. A client 214 should build a uni-directional tunnel from the client to a server if 215 and only if the server agrees to build a tunnel from the server to 216 the client. 218 2.3. Tunnel Requst and Tunnel Reply Messages 220 Tunnel Request and Tunnel Reply messages are designed to synchronize 221 building the bi-directional tunnel between a client and a server. 223 To build a tunnel, the client needs to know the IP address of the 224 server. However, the discovery of server addresses is not the purpose 225 of this document and should be specified elsewhere. 227 A client should maintain at least a tunnel to a server. Thus at the 228 system startup, the client should send a Tunnel Request to a server. 229 The client should retransmit Tunnel Request if it does not receive a 230 Tunnel Reply in a reasonable time, until it reaches a maximum number 231 of retransmissions. The client can build more tunnels to other 232 servers if necessary. 234 Upon receipt of a Tunnel Request, the server should respond with 235 a Tunnel Reply with a proper lifetime if the server can honor this 236 request. The server should build a uni-directional tunnel to the 237 client under the agreement with the client. 239 Upon receipt of a matched Tunnel Reply, the client should build a 240 uni-directional tunnel to the server. Thus the building of the 241 bi-directional tunnel is synchronized. 243 The bi-directional tunnel is valid within the lifetime granted by the 244 server. The client should extend the lifetime by starting another 245 transaction of Tunnel Request/Tunnel Reply before the tunnel expires. 247 2.4. Agent Solicitation Message 249 Agent Solictation messages are sent from mobile node to mobility 250 agents via clients and servers. If a mobile node or a client turns on 251 the P-bit in a solicitation, it means to know more information. A 252 client or a server receiving such a solicitation should respectively 253 append Client Proxy extension and Server Proxy extension to 254 subsequent Agent Advertisement messages. 256 On receiving an Agent Solicitation message, 258 - a client should tunnel the message to all the associated servers; 259 the client should set up a solicitation P-bit flag for the mobile 260 node if the message comes with the P-bit set; 262 - a server should forward the message to a link on which mobility 263 agents reside; the server should set up a solicitation P-bit flag 264 for the client if the message comes with the P-bit set; 266 - an agent should respond with an Agent Advertisement message. 268 2.5. Agent Advertisement Message 270 Agent Advertisement messages are critical to clients. A client can 271 enable a routing policy for an agent only if it receives an Agent 272 Advertisement. 274 To encourage a mobile node to issue Proxy Update messages, the P-bit 275 in advertisement should be turned on. If a mobility agent or a server 276 turns on the P-bit, it means to know more information. A server or a 277 client receiving such an advertisement should respectively append 278 Server Proxy extension and Client Proxy extension to subsequent Proxy 279 Update messages. 281 On receiving an Agent Advertisement, 283 - a server should tunnel the message to all the associated clients; 284 if there is a solicitation P-bit flag for a client, the server 285 should individually append a Server Proxy extension to the message 286 for the client; the server should update the advertisement P-bit 287 status for the agent with the P-bit in the message; 289 - a client should forward the message to the link on which mobile 290 nodes may visit, and enable a routing policy so that, all packets 291 addressed to the advertising agent can be tunneled to the server; 292 the routing policy is valid within the advertisement lifetime in 293 the message, and should be disabled upon its expiry; 295 if there is a solicitation P-bit flag for a mobile node, the client 296 should individually append a Client Proxy extension to the message 297 for the mobile node; the client should update the advertisement 298 P-bit status for the server with the P-bit in the message; 300 - a mobile node should update the advertisement P-bit status for the 301 agent or the client with the P-bit in the message; the mobile node 302 should send a Proxy Update message before starting a registration 303 procedure if the advertisement P-bit status for the agent or the 304 client is on. 306 2.6. Proxy Update Message 308 Proxy Update messages are critical to servers. A server can enable 309 a routing policy for a mobile node only if it receives a Proxy Update 310 message. 312 On receiving a Proxy Update message, 314 - a client should forward the message to the server, to which the 315 client imposed a routing policy for the agent specifed in the 316 message; 318 the client should append a Client Proxy extension to the message 319 if the advertisement P-bit status for the server is on; 321 - a server should enable a routing policy so that, all packets 322 addressed to the mobile node (specified in the message) can be 323 tunneled to the client, from which the message comes. The routing 324 policy is valid within the lifetime specified in the message, and 325 should be disabled upon its expiry. 327 The server should append a Server Proxy extension to the message 328 and forward the message to the agent (specified in the message) if 329 the advertisement P-bit status for the agent is on; 331 - an agent may locate the relevant mobile node, and redirect mobile 332 traffic to a relevant server if a change in the mobile node's 333 attachment is detected. 335 3. PPM Message Formats 337 The PPM model defines three types of UDP messages, with the first 338 one-octet defined as message type: 340 32 = Tunnel Request Message 341 33 = Tunnel Reply Message 342 34 = Proxy Update Message 344 The PPM model also requires two minor changes: a new flag bit must be 345 added to the Agent Solicitation message and the Agent Advertisement 346 message, replacing a previously unused, reserved bit in the message. 348 3.1. Tunnel Request Message 350 Tunnel Request is used for a client to request a tunnel from a server 351 to it. A client should maintain the tunnel or otherwise stop 352 forwarding Agent Advertisements. 354 IP fields: 356 Source Address Typically the interface address from which 357 the message is sent. 359 Destination Address Typically the IP address of the server. 361 UDP fields: 363 Source Port 365 Destination Port 434 367 The UDP header is followed by the fields shown below: 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Type | Reserved | Lifetime | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | | 375 + Identification + 376 | | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Extensions ... 379 +-+-+-+-+-+-+-+- 381 Type 32 (Tunnel Request) 383 Reserved sent as zero; ignored on reception. 385 Lifetime 386 The number of seconds remaining before the tunnel is 387 considered expired. A value of zero indicates a request 388 for disconnection. A value of 0xffff indicates infinity. 390 Identification 391 A 64-bit number, constructed by the client, used for 392 matching Tunnel Requests with Tunnel Replies, and for 393 protecting against replay attacks of tunnel messages. 395 Extensions 396 The fixed portion of the Registration Request is followed 397 by one or more of the Extensions. 399 3.2. Tunnel Reply Message 401 A server returns a Tunnel Reply message to a client which has sent a 402 Tunnel Request (Section 3.1) message. The Reply message contains the 403 necessary codes to inform the client about the status of its Request, 404 along with the lifetime granted by the server, which MAY be smaller 405 than the original Request. 407 IP fields: 409 Source Address Typically copied from the destination 410 address of the Tunnel Request to which 411 the server is replying. 413 Destination Address Copied from the source address of the 414 Tunnel Request to which the server is replying 416 UDP fields: 418 Source Port 420 Destination Port Copied from the source port of the 421 corresponding Tunnel Request 423 The UDP header is followed by the fields shown below: 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type | Code | Lifetime | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | | 431 + Identification + 432 | | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Extensions ... 435 +-+-+-+-+-+-+-+- 437 Type 33 (Tunnel Reply) 439 Code A value indicating the result of the Tunnel Request. 440 See below for a list of currently defined Code values. 442 Lifetime 443 If the Code field indicates that the server agrees to 444 build the tunnel, the Lifetime field is set to the number 445 of seconds remaining before the tunnel is considered 446 expired. A value of zero indicates that the tunnel has 447 been disconnected. A value of 0xffff indicates infinity. 448 If the Code field indicates that the tunnel was denied, 449 the contents of the Lifetime field are unspecified and 450 MUST be ignored on reception. 452 Identification 453 A 64-bit number used for matching Tunnel Requests with 454 Tunnel Replies, and for protecting against replay attacks 455 of tunnel messages. The value is based on the 456 Identification field from the Tunnel Request message from 457 the client. 459 Extensions 460 The fixed portion of the Registration Reply is followed 461 by one or more of the Extensions. 463 The following values are defined for use within the Code field. 465 0 tunnel connected 467 64 reason unspecified 468 65 administratively prohibited 469 66 insufficient resources 470 67 client failed authentication 471 68 requested Lifetime too long 472 69 poorly formed message 474 Up-to-date values of the Code field are specified in the most recent 475 "Assigned Numbers" [10]. 477 3.3. Proxy Update Message 479 Proxy Update messages are used not only for server to enable routing 480 policies, but for client, server and mobility agent to keep track of 481 mobile nodes. A Proxy Update can be sent from a mobile node to a 482 client, from the client to a server, and from the server to the agent 483 in that order. A mobile node should issue Proxy Update periodically. 485 IP fields: 487 Source Address Typically the interface address from which 488 the message is sent. 490 Destination Address Typically that of the client, the server or 491 the agent if the message is sent from the 492 mobile node, the client or the server, 493 respectively. 495 UDP fields: 497 Source Port 499 Destination Port 434 501 The UDP header is followed by the fields shown below: 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Type | Reserved | Lifetime | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Home Address | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Agent Address | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Extensions ... 513 +-+-+-+-+-+-+-+- 515 Type 34 (Proxy Update) 517 Reserved sent as zero; ignored on reception. 519 Lifetime 520 The number of seconds remaining before the mobile node is 521 considered away from a client. 523 Home Address 524 The home address of the mobile node. 526 Agent Address 527 The mobility agent address at the interface towards the 528 mobile node. 530 Extensions 531 The fixed portion of the Proxy Update is followed by one 532 or more of the Extensions 534 3.4. Agent Solicitation Message 536 One bit is added to the flag bits in the Agent Solicitation message 537 to indicate an intent to receive more information from subsequent 538 Agent Advertisement messages. 540 Thus, the Agent Solicitation message under the PPM model is: 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Type | Code | Checksum | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 |P| Reserved | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Proxy (P) 552 The Proxy (P) bit is set by the mobile node or the client 553 to indicate its intent to receive more information from 554 subsequent Agent Advertisement messages. 556 3.5. Agent Advertisement Message 558 One bit is added to the flag bits in the Agent Advertisement message 559 to indicate an intent to receive Proxy Update messages or to receive 560 more information from subsequent Proxy Update messages. 562 Thus, the Agent Advertisement message under the PPM model begins as 563 follows: 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Type | Length | Sequence Number | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Registration Lifetime |R|B|H|F|M|G|V|T|P| reserved | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | (unchanged...) 573 +-+-+- 575 Proxy (P) 577 The Proxy (P) bit is set by the agent or the client to indicate 578 its intent to receive Proxy Update messages, or by the server 579 or the client to indicate its intent to receive more 580 information from subsequent Proxy Update messages. A client 581 MUST have this bit set when it forwards an Agent Advertisement 582 message. 584 4. PPM Extension Formats 586 The PPM model defines the following Mobile IP message extensions: 588 112 = Server Proxy Extension 589 113 = Client Proxy Extension 590 114 = Mobile-Client Authentication Extension 591 115 = Client-Server Authentication Extension 592 116 = Server-Agent Authentication Extension 594 The PPM messages may include Mobile-Foreign Authentication extension 595 defined in [1]. 597 This section describes each of the new PPM message extensions. 599 4.1. Server Proxy Extension 601 The Server Proxy extension may be included in an Agent Advertisement 602 message, or a Proxy Update message. 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Type | Length | No. of Agents | No. of Clients| 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Server Address | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 Type 112 614 Length 12 616 No. of Agents The number of agents on the same link as the 617 server. 619 No. of Clients The number of clients associated with the 620 server over tunnels. 622 Server Address The IP address of the server proxy 624 4.2. Client Proxy Extension 626 The Client Proxy extension may be included in an Agent Advertisement 627 message or a Proxy Update message. 629 0 1 2 3 630 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 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Type | Length | No. of Servers| No. of MNs | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Client Address | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Type 113 639 Length 12 641 No. of Servers The number of servers associated with the 642 client over tunnels. 644 No. of MNs The number of mobile nodes on the same link 645 as the client. 647 Client Address The IP address of the client proxy 649 4.3. Mobile-Cleint Authentication Extension 651 This extension MAY be present in Proxy Update messages from a mobile 652 node to a client, in cases in which a mobility security association 653 exists between the mobile node and the client. 655 0 1 2 3 656 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 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Type | Length | SPI .... 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 ... SPI (cont.) | Authenticator ... 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 Type 114 665 Length 4 plus the number of bytes in the Authenticator. 667 SPI Security Parameter Index (4 bytes). An opaque 668 identifier 670 Authenticator (variable length) 672 4.4. Client-Server Authentication Extension 674 This extension MUST be present in Agent Solicitation messages, Agent 675 Advertisement messages and Proxy Update messages between a client to 676 a server. The document requires that a proxy security association 677 must exist between the client and the server. 679 0 1 2 3 680 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 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Type | Length | SPI .... 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 ... SPI (cont.) | Authenticator ... 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 Type 115 689 Length 4 plus the number of bytes in the Authenticator. 691 SPI Security Parameter Index (4 bytes). An opaque 692 identifier 694 Authenticator (variable length) 696 4.5. Server-Agent Authentication Extension 698 This extension MAY be present in a Proxy Update message from a server 699 to an agent, in cases in which a mobility security association exists 700 between the server and the agent. 702 0 1 2 3 703 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 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Type | Length | SPI .... 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 ... SPI (cont.) | Authenticator ... 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Type 116 712 Length 4 plus the number of bytes in the Authenticator. 714 SPI Security Parameter Index (4 bytes). An opaque 715 identifier 717 Authenticator (variable length) 719 5. Mobile Node Considerations 721 The PPM model requires that a mobile node keep looking at the P-bit 722 and the source link address in received Agent Advertisement messages. 724 An advertisement without P-bit set is directly from a mobility agent. 725 An advertisement with P-bit set is from either a mobility agent or a 726 client. 728 A change in the source IP address of advertisement means that a 729 different agent has been detected. But a change in the source link 730 address means that a different client has been detected. 732 A mobile node is considered away from an agent if, the mobile node 733 does not receive any advertisement from the agent IP address within 734 the advertisement lifetime. A mobile node is considered away from a 735 client if, the mobile node does not receive any advertisement from 736 the client link address within the advertisement lifetime. 738 5.1. Sending Agent Solicitation 740 The mobile node MAY send an Agent Solicitation message with P-bit 741 set to request more information from clients or agents. 743 5.2. Receiving Agent Advertisement 745 Once the mobile node receives an Agent Advertisement, it MUST update 746 the advertisement P-bit status for the agent or the client with the 747 P-bit in the message, and copy its source IP address and source link 748 address. 750 If the P-bit status changes from on to off, the mobile node SHOULD 751 stop sending Proxy Update messages. But if the P-bit status changes 752 from off to on, the mobile node MUST send Proxy Update messages as 753 in section 5.4. 755 If the agent table is empty before the mobile node receives this 756 advertisement with P-bit set, the mobile node SHOULD send Proxy 757 Update messages before attempting to register a binding. 759 5.3. Handover 761 When the mobile node considers itself away from the agent currently 762 serving it, it SHOULD check its agent table to find another agent. If 763 there is no more agent on the table, no further action SHOULD be 764 taken. Otherwise, before the mobile node attempts to register a new 765 binding with the new agent, 766 - if the client associated with the disappearing agent is still on 767 the client table and also sends advertisements on behalf of the new 768 agent, the mobile node SHOULD put the new agent address in the 769 subsequent Proxy Update messages to this client; 771 - or otherwise, the mobile node MUST stop sending Proxy Update 772 messages to this client, choose another client that is sending 773 advertisements on behalf of the new agent, and send Proxy Update 774 messages to the new client by updating with the new agent. 776 If the mobile node is not away from the agent currently serving it 777 but away from the client currently serving it, it MUST stop sending 778 Proxy Update messages to the client. It SHOULD search its client 779 table for another client that is sending advertisements on behalf of 780 the same agent. A failure in this search is an error and SHOULD be 781 logged. If there is such a client, the mobile node SHOULD send Proxy 782 Update messages to the new client by updating with the agent. 784 5.4. Sending Proxy Update 786 The mobile node SHOULD send Proxy Update messages 788 - before it attempts to register a binding and the P-bit status for 789 the relevant agent or client is on; or 791 - if the mobile node is away from the client currently serving it, 792 and has chosen a new client on the client table. 794 The lifetime in the Proxy Update is the time within which the mobile 795 node is considered reachable to the client. The mobile node SHOULD 796 send a new Proxy Update message before it is considered away from the 797 client, unless the mobile node does not require the service from the 798 agent via the client. 800 The mobile node MAY append a Mobile-Client Authetication extension to 801 the Proxy Update messages if there exists the mobility security 802 association between the mobile node and the client. 804 6. Client Proxy Considerations 806 A client works on behalf of mobility agents. It can be associated 807 with an agent upon receipt of an Agent Advertisement message. To 808 receive such an advertisement, a tunnel from a server to it SHOULD 809 be built up by sending Tunnel Request message. 811 6.1. Sending Tunnel Request 813 At the system startup, A client SHOULD build up at least one tunnel 814 to a server. The discovery of server addresses is not the purpose of 815 this document, and SHOULD be discussed elsewhere. 817 To build a bidirectional tunnel between a client and a server, the 818 client SHOULD send a Tunnel Request to the server. The client SHOULD 819 include a desired lifetime in the Tunnel Request. 821 The client SHOULD retransmit Tunnel Request if it has not received 822 a matched Tunnel Reply in a reasonable time. Failure in receipt of 823 such a Tunnel Reply message after a maximum of retransmissions SHOULD 824 be logged for further administrative option. 826 The identification SHOULD be implemented as a timestamp or a nonce 827 specified in the base protocol [1]. 829 The client SHOULD append a Client-Server Autentication extension to 830 the Tunnel Request message. The PPM model requires that there be a 831 proxy security association between the client and the server. 833 6.2. Receiving Tunnel Reply 835 Upon receipt of a Tunnel Reply, the client MUST check the validity of 836 the message. The reply is valid if 838 - the UDP checksum is valid; 840 - the low-order 32 bits of the Identification field in the Tunnel 841 Reply equals to the low-order 32 bits of the Identification field 842 in the most recent Tunnel Request sent to the server; AND 844 - the reply include a Client-Server Autentication extension at the 845 end and the Authenticator is valid. 847 An invalid reply SHOULD be discarded and an error SHOULD be logged. 849 If the code field indicates that the server refuses to build the 850 tunnel because the lifetime is too long, the client MAY resend a 851 Tunnel Request with a proper lifetime. 853 If the code field indicates that the server refuses to build the 854 tunnel, but there already exists a tunnel to the server, the tunnel 855 SHOULD remain until its expiry. The code SHOULD be logged. 857 If the code field is positive but the lifetime is zero, the client 858 MUST remove the existing tunnel to the server if any. 860 If the server agrees to build the tunnel by granting a proper 861 lifetime, the client MUST build or reset the unidirectional tunnel to 862 the server. The tunnel is valid within the granted lifetime and 863 SHOULD be removed upon its expiry. To extend the lifetime of the 864 tunnel, the client SHOULD send a Tunnel Request message to the server 865 a reasonable time before the tunnel expires. 867 6.3. Receiving Agent Solicitation 869 If the client receives an Agent Solicitation message, it SHOULD 870 set up a solicitation P-bit flag for the mobile node if the message 871 comes with the P-bit set, and MUST tunnel it to all the associated 872 servers. The client MAY turn on the P-bit to request more information 873 from servers. 875 The client SHOULD append a Client-Server Autentication extension to 876 the solicitation message. The PPM model requires that there be a proxy 877 security association between the client and the server. 879 6.4. Receiving Agent Advertisement 881 Upon receipt of an Agent Advertisement, the client MUST check the 882 validity of the message. The advertisement is valid if 884 - the ICMP checksum is valid; 886 - it is received from a tunnel; AND 888 - the message includes a Client-Server Autentication extension at the 889 end and the Authenticator is valid. 891 An invalid advertisement SHOULD be silently discarded. 893 If the client receives a valid Agent Advertisement message, it SHOULD 894 update the advertisemnt P-bit status for the server with the P-bit in 895 the advertisement. The client SHOULD forward the advertisement to the 896 link on which the client serves mobile nodes. In the advertisement to 897 be forwarded, the client MUST turn on the P-bit and strip off the 898 Client-Server Authetication extension. If there is a solicitation 899 P-bit flag for a mobile node, the client SHOULD individually append a 900 Client Proxy Extension for the mobile node. 902 the client MUST additionally enable a routing policy so that all 903 packets addressed to the advertising agent can be tunneled to the 904 server from which the message comes. The routing policy is valid 905 within the the advertisement lifetime and SHOULD be disabled upon its 906 expiry. 908 6.5. Receiving Proxy Update 910 Upon receipt of a Proxy Update message from a mobile node, the client 911 MUST check the validity of the message. The Proxy Update is valid if 913 - the UDP checksum is valid; 915 - there is a routing policy for tunneling to a server all the packets 916 destined for the agent specified in the message; AND 918 - the Authenticator is valid if the message includes a Mobile-Client 919 Autentication extension at the end. 921 An invalid Proxy Update SHOULD be silently discarded. 923 The client MUST forward a valid Proxy Update message to the relevant 924 server. In the message to be forwarded, the client MUST strip off 925 the Mobile-Client Authetication extension if any, and SHOULD append a 926 Client Proxy extension if the advertisement P-bit status for the 927 server is on. 929 The client SHOULD additionally append a Client-Server Autentication 930 extension to the message. The PPM model requires that there be a 931 proxy security association between the client and the server. 933 7. Server Proxy Considerations 935 A server works on behalf of mobile nodes. It can be associated with a 936 mobile node upon receipt of a Proxy Update message. To receive such a 937 message, a tunnel from a client to it SHOULD be built up by answering 938 Tunnel Request with Tunnel Reply. 940 7.1. Receiving Tunnel Request 942 Upon receipt of a Tunnel Request, the client MUST check the validity 943 of the message. The request is valid if 945 - the UDP checksum is valid; AND 947 - the message includes a Client-Server Autentication extension at the 948 end and the Authenticator is valid. 950 An invalid request SHOULD be discarded and an error SHOULD be logged. 952 On receipt of a valid Tunnel Request message, the server SHOULD 953 respond with a Tunnel Reply with lower 32-bit identification copied 954 from the original request. 956 If the server is not able to honor the request, it SHOULD put a 957 proper code in the reply. 959 If the server denies the request and remove the existing tunnel to 960 the client, it SHOULD set the code to a positive value (0) and the 961 lifetime to 0. 963 Otherwise, if the server agrees to build or reset a tunnel to the 964 client, it SHOULD set the code to a positive value (0) and the 965 lifetime to a value not greater than that in the original Request. 966 The server MUST build a tunnel to the client if there is not such a 967 tunnel, or reset the existing tunnel to the client with the granted 968 lifetime. The tunnel is valid within the granted lifetime and SHOULD 969 be removed upon its expiry. 971 7.2. Receiving Agent Solicitation 973 Upon receipt of an Agent Solicitation, the server MUST check the 974 validity of the message. The solicitation is valid if 976 - the ICMP checksum is valid; 978 - it is received from a tunnel; AND 980 - the message includes a Client-Server Autentication extension at the 981 end and the Authenticator is valid. 983 An invalid solicitation SHOULD be silently discarded. 985 If the server receives a valid Agent Solicitation message, it SHOULD 986 set up a solicitation P-bit flag for the client if the message comes 987 with the P-bit set, and MUST broadcast the message on the link 988 connected to a mobility agent. The server MUST strip off the Client- 989 Server Autentication extension from the broadcast message. 991 7.3. Receiving Agent Advertisement 993 Upon receipt of an Agent Advertisement message, the server SHOULD 994 update the advertisement P-bit status with the P-bit in the message, 995 and MUST tunnel the message to the relevant client if it is a 996 unicast, or to all the associated clients if it is a broadcast. If 997 there is a solicitation P-bit flag for a client, the server SHOULD 998 individually append a Server Proxy extension for the client. 1000 The server SHOULD append a Client-Server Autentication extension to 1001 the advertisement message. The PPM model requires that there be a 1002 proxy security association between the server and the server. 1004 7.4. Receiving Proxy Update 1006 Upon receipt of a Proxy Update message, the server MUST check the 1007 validity of the message. The Proxy Update is valid if 1009 - the UDP checksum is valid; 1011 - it is received from a tunnel; AND 1013 - the message includes a Client-Server Autentication extension at the 1014 end and the Authenticator is valid. 1016 An invalid Proxy Update SHOULD be silently discarded. 1018 Upon receipt of a valid Proxy Update message, the server MUST enable 1019 a routing policy so that all packets addressed to the mobile node 1020 (specified in the message) can be tunneled to the client from which 1021 the message comes. The routing policy is valid within the lifetime 1022 specified in the Porxy Update message and SHOULD be disabled upon its 1023 expiry. 1025 If the advertisement P-bit status for the agent is on, the server 1026 SHOULD forward the message to the agent. In this message, the server 1027 MUST strip off the Client-Server Autentication extension, SHOULD 1028 append a Server Proxy extension, and MAY append a Server-Agent 1029 Authetication extension. 1031 8. Agent Considerations 1033 In general, the PPM model does not impose more requirements to the 1034 mobility agent. But an enhancement to the agent is recommended. 1036 8.1. Receiving Agent Solicitation 1038 There is no further requirement and enhancement to this message for 1039 mobility agents. 1041 8.2. Sending Agent Advertisement 1043 A mobility agent MAY refuse to receive Proxy Update messages by 1044 turning off the P-bit in Agent Advertisement messages. 1046 If the agent intends to keep track of mobile nodes, however, it 1047 SHOULD turn on the P-bit in Agent Advertisement messages. 1049 8.3. Receiving Proxy Update 1051 An mobility agent MAY silently discard a received Proxy Update 1052 message if it does not support the PPM model. 1054 If the agent supports the PPM model, upon receipt of a Proxy Update 1055 message, the agent MUST check the validity of the message. The Proxy 1056 Update is valid if 1058 - the UDP checksum is valid; 1060 - the Authenticator is valid if the message includes a Server-Agent 1061 Autentication extension at the end. 1063 An invalid Proxy Update SHOULD be silently discarded. 1065 If the agent intends to keep track of mobile nodes, however, it 1066 SHOULD look into the message. Packets addressed to the mobile node 1067 SHOULD be sent to a server or the mobile node, from which a most 1068 recent Proxy Update was received. In addition, the agent SHOULD 1069 balance traffic load among servers by looking into Proxy Update 1070 messages. 1072 9. Security Considerations 1074 The security issue is open for further discussion. 1076 References 1078 [1] Charles Perkins, editor. IP mobility support. RFC 2002, 1079 October 1996. 1081 [2] Charles Perkins. Mobile-IP Local Registration with 1082 Hierarchical Foreign Agents. Internet Draft, 1083 draft-perkins-mobileip-hierfa-00.txt, February 1996. Work in 1084 progress. 1086 [3] W. Simpson. IP in IP Tunneling. RFC 1853, October 1995. 1088 [4] Charles Perkins. IP Encapsulation within IP. RFC 2003, 1089 October 1996. 1091 [5] Charles Perkins. Minimal Encapsulation within IP. RFC 2004. 1092 October 1996. 1094 [6] David B. Johnson and Charles Perkins. Route Optimization in 1095 Mobile IP. Internet Draft, draft-ietf-mobileip-optim-04.txt, 1096 February 1996. Work in progress. 1098 [7] David C. Plummer. An Ethernet Address Resolution Protocol: 1099 Or Converting Network Protocol Addresses to 48.bit Ethernet 1100 Addresses for Transmission on Ethernet Hardware. RFC 826, 1101 November 1982. 1103 [8] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. 1105 [9] J. B. Postel, Editor. Internet Protocol. RFC 791, September 1106 1981. 1108 [10] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700, 1109 October 1994. 1111 Author's Address 1113 Questions about this memo can also be directed to: 1115 Yunzhou Li 1116 Department of Information Systems and Computer Science 1117 National University of Singapore 1118 Lower Kent Ridge Road 1119 Singapore 119260 1121 Work: +65 772-6891 (Y.C. Tay c/o) 1122 Fax: +65 779-5452 (Y.C. Tay c/o) 1123 E-mail: scip4166@nus.sg