idnits 2.17.1 draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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. ** The abstract seems to contain references ([Hinden,1998]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (July 1, 2002) is 7969 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) -- Missing reference section? 'Hinden' on line 66 looks like a reference -- Missing reference section? '1998' on line 66 looks like a reference -- Missing reference section? 'Partridge' on line 80 looks like a reference -- Missing reference section? '1993' on line 80 looks like a reference -- Missing reference section? 'Haberman' on line 287 looks like a reference -- Missing reference section? '2001' on line 287 looks like a reference -- Missing reference section? 'Elz' on line 368 looks like a reference -- Missing reference section? '1997' on line 368 looks like a reference -- Missing reference section? 'Sollins' on line 371 looks like a reference -- Missing reference section? '1992' on line 371 looks like a reference -- Missing reference section? 'Crawford' on line 406 looks like a reference -- Missing reference section? '2002' on line 406 looks like a reference -- Missing reference section? 'Stewart' on line 410 looks like a reference -- Missing reference section? '2000' on line 410 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Jun-ichiro itojun Hagino 3 INTERNET-DRAFT IIJ Research Laboratory 4 Expires: January 1, 2003 K. Ettikan 5 Intel ASG, Malaysia 6 July 1, 2002 8 An analysis of IPv6 anycast 9 draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as ``work in progress.'' 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 Distribution of this memo is unlimited. 30 The internet-draft will expire in 6 months. The date of expiration will 31 be January 1, 2003. 33 Abstract 35 The memo tries to identify the problems and issues in the use of IPv6 36 anycast [Hinden, 1998] defined as of today. The goals of the draft are 37 (1) to understand the currently-defined IPv6 anycast better, (2) to 38 provide guidelines for people trying to deploy anycast services, and (3) 39 to suggest updates to IPv6 anycast protocol specification. 41 The document was made possible by input from ipngwg DNS discovery design 42 team. 44 1. IPv6 anycast 46 "Anycast" is a communication model for IP, just like unicast and 47 multicast are. 49 Anycast can be understood best by comparing with unicast and multicast. 50 IP unicast allows a source node to transmit IP datagrams to a single 51 destination node. The destination node is identified by a unicast 52 address. IP multicast allows a source node to transmit IP datagrams to 53 a group of destination nodes. The destination nodes are identfied by a 54 multicast group, and we use a multicast address to identify the 55 multicast group. 57 IP anycast allows a source node to transmit IP datagrams to a single 58 destination node, out of a group of destination nodes. IP datagrams 59 will reach the closest destination node in the set of destination nodes, 60 based on the routing measure of distance. The source node does not need 61 to care about how to pick the closest destination node, as the routing 62 system will figure it out (in other words, the source node has no 63 control over the selection). The set of destination nodes is identified 64 by an anycast address. 66 Anycast was adopted by IPv6 specification suite. RFC2373 [Hinden, 1998] 67 defines the IPv6 anycast address, and its constraints in the usage. The 68 following sections try to analyze RFC2373 rules, and understand 69 limitations with them. At the end of the draft we compile a couple of 70 suggestions to exisitng proposals, for extending the usage of the IPv6 71 anycast. 73 2. Existing practices 75 There are multiple examples of anycast in IPv4. The section tries to 76 summarize those practices. 78 2.1. RFC1546 anycast 80 RFC1546 [Partridge, 1993] defines an experimental anycast service for 81 IPv4. With RFC1546, anycast address is distinguishable from unicast 82 address (unlike RFC2373 anycast), as they are allocated from separate 83 range. The authors have no knowledge whether RFC1546 anycast is widely 84 practiced or not; our bet is that it is not. 86 2.2. Pseudo-anycast: multiple hosts with single unicast address 88 There are existing practices of using a single unicast address at 89 multiple different locations, for load balancing purposes, for DNS 90 servers and web servers (1992 Olympic games) [Hardie, 2002; Ohta, 2000] 91 . We call the technique "pseudo-anycast" for clarity in this document. 92 The pseudo-anycast works as follows: 94 o A provider-independent IPv4 address prefix is allocated from an RIR. 96 o The address prefix is configured at multiple distant locations on the 97 Internet. 99 o BGP routes are advertised from all of the locations. 101 o Clients will reach the nearest location based on the BGP routes. 103 Pseudo-anycast must not be confused with the one we discuss in the 104 document (RFC2373 anycast), as the problem domain is different. 106 Pseudo-anycast tries to replicate unicast servers in distant domains. 107 The distribution of servers is worldwide. Pseudo-anycast is being used 108 for specific upper-layer protocols only, like DNS and HTTP. There is no 109 consideration given for the cases when a client contacts multiple 110 servers by chance (transport layer protocol will get confused), since it 111 is unlikely to see BGP route changes during the short lifetime of the 112 transport layer protocols being used. 114 RFC2373 anycast is defined in more generic manner, and does not limit 115 the routing infrastructure nor upper-layer protocol. Therefore, RFC2373 116 imposes certain limitation to the packet header contents (like IPv6 117 source address), to prevent confusions due to routing changes during the 118 lifetime of a transport-layer connection. 120 This document tries to analyze RFC2373 anycast to understand if we can 121 use it for site-scoped server replication, upper-layer protocols other 122 than DNS or HTTP, and such. Still, it is possible to apply pseudo- 123 anycast to IPv6. Issues with pseudo-anycast on IPv6 are outside of the 124 scope of the document. 126 3. Limitations/properties in the current proposals 128 3.1. Identifying anycast destination 130 For anycast addresses, RFC2373 uses the same address format as unicast 131 addresses. Therefore, without other specific configurations, a sender 132 usually cannot identify if the sender is sending a packet to anycast 133 destination, or unicast destination. This is different from RFC1546 134 IPv4 anycast, where anycast address is distinguishable from unicast 135 addresses. 137 3.2. Nondeterministic packet delivery 139 If multiple packets carry an anycast address in IPv6 destination address 140 header, these packets may not reach the same destination node, depending 141 on stability of the routing table. This property leads to a couple of 142 interesting symptoms. 144 If we can assume that the routing table is stable enough during a 145 protocol exchanges, multiple packets (with anycast address in 146 destination address field) will reach the same destination node just 147 fine. However, there is no such guarantee. 149 If routing table is not stable enough or you would like to take a more 150 strict approach, a client can only send one packet with anycast address 151 in the destination address field. For example, consider the following 152 packet exchange. The following exchange can lead us to failure, as we 153 are not sure if the 1st and 2nd anycast packet have reached the same 154 destination. 156 query: client unicast (Cu) -> server anycast (Sa) 157 reply: server unicast (Su) -> client unicast (Cu) 158 query: client unicast (Cu) -> server anycast (Sa) 159 It may reach a different server! 160 reply: server unicast (Su) -> client unicast (Cu) 162 Because of the non-determinism, if we take a strict approach, we can use 163 no more than 1 packet with anycast destination address, in a set of 164 protocol exchange. If we use more than 2 packets, 1st and 2nd packet 165 may reach different server and may cause unexpected results. If the 166 protocol is completely stateless, and we can consider the first 167 roundtrip and second roundtrip separate, it is okay. For stateful 168 protocols, it is suggested to use anycast for the first packet in the 169 exchange, to discover unicast address of the (nearest) server. After we 170 have discovered the unicast address of the server, we should use the 171 server's unicast address for the protocol exchange (note that there is 172 some security implication here - see Security Consideration section). 174 Also because of non-determinism, if we are to assign an IPv6 anycast 175 address to servers, those servers must provide uniform services. For 176 example, if server A and server B provide different quality of service, 177 and people wants to differentiate between A and B, we cannot use single 178 IPv6 anycast address to identify both A and B. 180 Note that, this is not a bad feature of anycast; this property lets us 181 use anycast addresses for load balancing. Also, packets will 182 automatically be delivered to the nearest node with anycast address 183 assigned. Anaycast will ease service locating problem by pusing the 184 task to network layer rather than handled by upper layers. 186 Here are situations where multiple packets with anycast destination 187 address can lead us to problems: 189 o Fragmented IPv6 packets. Fragments may reach multiple different 190 destinations, and will prevent reassembly. 192 Because the sending node cannot differentiate between anycast addresses 193 and unicast addresses, it is hard for the sending node to control the 194 use of fragmentation. 196 3.3. Anycast address assignment to hosts 198 RFC2373 suggests to assign anycast addresses to a node, only when the 199 node is a router. This is because there was no standard way for hosts 200 to announce their intention to accept packets toward anycast addresses. 202 If no hosts have anycast address on them, it is easier for us to route 203 an IP datagram to anycast destination. We just need to follow existing 204 routing entries, and we will eventually hit a router that has the 205 anycast address. If we follow RFC2373 restriction strictly, we could 206 only assign anycast addresses onto routers. 208 3.4. Anycast address in source address 210 Under RFC2373, IPv6 anycast address can not be put into IPv6 source 211 address. This is basically because an IPv6 anycast address does not 212 identify a single source node. 214 o Incorrect reassembly of fragmented packets due to multiple anycast 215 members sending packets with the same fragment ID to the same 216 destination at about the same time; the same the source IP address, 217 destination IP address, nextheader, and fragment ID numbers might be 218 accidentally used at the same time by different senders. 220 o Errors and other response packets might be delivered to a different 221 anycast member than sent the packet. This might be very likely since 222 asymmetric routing is rather prevalent on the Internet. 224 Particular cases of such errors that are known to cause protocol 225 problems are (1) ICMP packet too big making path MTU discovery 226 impossible. (2) (could be more) The misdelivery of other errors might 227 cause operational problems - making the network harder to trouble- 228 shoot when anycast source addresses are used. 230 3.5. IPsec 232 IPsec and IKE identify nodes by using source/destination address pairs. 233 Due to the combination of issues presented above, it is difficult to use 234 IPsec on packets with anycast address in source address, destination 235 address, or both. 237 Even with manual keying, IPsec trust model with anycast address is 238 confusing. As IPsec uses IPv6 destination address to identify which 239 IPsec key to be used, we need to use the same IPsec key for all of the 240 anycast destinations that share an anycast address. 242 IPsec protocol has replay protection mechanism. If IPsec is used with 243 an anycast address, it will not work well as replay counter will not be 244 updated consistently due to the anycast packet delivery. 246 Dynamic IPsec key exchange (like IKE) is almost impossible. First of 247 all, to run IKE session between two nodes, the two nodes need to be able 248 to communicate with each other. With nondeterministic packet delivery 249 provided by anycast, it is not quite easy. Even if we could circumvent 250 the issue with IKE, we have exactly the same problem as manual keying 251 case for actual communication. 253 4. Possible improvements and protocol changes 255 4.1. Assigning anycast address to hosts (non-router nodes) 257 Under RFC2373 rule, we can only assign anycast addresses to routers, not 258 to hosts. The restriction was put into the RFC because it was felt 259 insecure to permit hosts to inject host routes to anycast address. 261 If we try to ease the restriction and assign anycast addresses to IPv6 262 hosts (non-routers), we would need to inject host routes for the anycast 263 addresses, with prefix length set to /128, into the IPv6 routing system. 264 We will inject host routes from each of the nodes with anycast 265 addresses, to make packets routed to a topologically-closest node. Or, 266 we may be able to inject host routes from routers adjacent to the 267 servers (not from the servers themselvers). 269 Here are possible ways to allow anycast addresses to be assigned to 270 hosts. We would need to diagnose each of the following proposals 271 carefully, as they have different pros and cons. The most serious issue 272 would be the security issue with service blackhole attack (malicious 273 party can blackhole packets toward anycast addresses, by making false 274 advertisement). 276 o Let the host with anycast address to participate into routing 277 information exchange. The host does not need to fully participate; it 278 only needs to announce the anycast address to the routing system. To 279 secure routing exchange, administrators need to configure secret 280 information that protects the routing exchange to the host, as well as 281 other routers. 283 o Develop a protocol for a router, to discover hosts with anycast 284 address on the same link. The router will then advertise the anycast 285 address to the routing system. This could be done by an extension to 286 IPv6 Neighbor Discovery or an extension to IPv6 Multicast Listener 287 Discovery [Haberman, 2001] . 289 The impact of host routes depends on the scope of the anycast address 290 usage. For example, if we use site-local anycast address to identify a 291 set of servers, the propagation of host route is limited inside the 292 site. If the site administration policy permits it, and the site 293 routers can handle the additional routing entries, the additional host 294 routes are okay. So, we can safely assign anycast address to non-router 295 nodes (hosts), and inject host route for the anycast address, into the 296 site IPv6 routing system. It is still questionable to inject host 297 routes into worldwide IPv6 routing system, as it has problems in terms 298 of scalability. Also, because of IPv6 route aggregation rules [Rockell, 299 2000] it is normally impossible to propagate IPv6 host routes worldwide. 301 4.2. Anycast address in destination address 303 By using anycast in IPv6 layer, upper-layer protocols may be able to 304 enjoy redundancy and higher availability of servers. However, for 305 stateful upper-layer protocols, a client may need to specify a single 306 node out of nodes that share an anycast address. Suppose a client C 307 would like to communicate a specific server with anycast address, Si. 308 Si shares the same anyast address with other servers, S1 to Sn. It is 309 hard for C to selectively communicate with Si. 311 One possible workaround is to use IPv6 routing header. By specifying a 312 unicast address of Si as an intermediate hop, C can deliver the packet 313 to Si, not to other Sn. 315 Note that, however, by specifying Si explicitly, C now have lost the 316 server redundancy provided by the use of anycast address in IPv6 layer. 317 If Si goes down, the communication between C and Si will be lost. C 318 cannot enjoy the failure resistance provided by redundant servers, S1 to 319 Sn. Protocol designers should carefully diagnose if any state is 320 managed by C and/or Si, and decide how the protocol should take 321 advantage of anycast addresses and their characteristics. 323 4.3. Anycast address in source address 325 Under RFC2373 rule, anycast address cannot be put into source address. 326 Here is a possible workaround, however, it could not win a consensus in 327 the past ipngwg meetings: 329 o When we try to use anycast address in the source address, use a (non- 330 anycast) unicast address as the IPv6 source address, and attach home 331 address option with anycast address. In ipngwg discussions, however, 332 there seem to be a consensus that the home address option should have 333 the same semantics as the source address in the IPv6 header, so we 334 cannot put anycast address into the home address option. 336 5. Upper layer protocol issues 338 5.1. Use of UDP with anycast 340 Many of the UDP-based protocols use source and destination address pair 341 to identify the traffic. One example would be DNS over UDP; most of the 342 DNS client implementation checks if the source address of the reply is 343 the same as the destination address of the query, in the fear of the 344 fabricated reply from a bad guy. 346 query: client unicast (Cu) -> server unicast (Su*) 347 reply: server unicast (Su*) -> client unicast (Cu) 349 addresses marked with (*) must be equal. 351 If we use server's anycast address as the destination of the query, we 352 cannot meet the requirement due to RFC2373 restriction (anycast address 353 cannot be used as the source address of packets). Effectively, client 354 will consider the reply is fabricated (hijack attempt), and drops the 355 packet. 357 query: client unicast (Cu) -> server anycast (Sa) 358 reply: server unicast (Su) -> client unicast (Cu) 360 Note that, however, bad guys can still inject fabricated results to the 361 client, even if the client checks the source address of the reply. The 362 check does not improve security of the exchange at all. 364 If we check the existing protocol descriptions, in many cases, it is not 365 possible to perform sanity checks against IP source address for UDP 366 exchanges. Either they are not specified on the protocol documents, or 367 it is an implementation mistake to check the IP source address. For 368 example, from RFC2181 [Elz, 1997] section 4.1, we cannot check IP source 369 address matches for UDP DNS packets (client shouldn't be checking this). 370 There is no wording available on the selection of source address, in 371 TFTP protocol specification [Sollins, 1992] . 373 So, regarding to this issue, we conclude as follows: 375 o To use anycast address on the UDP protocol exchange, client side 376 should not check the source address of the incoming packet. Packet 377 pairs must be identified by using UDP port numbers or upper-layer 378 protocol mechanisms (like cookies). The source address check itself 379 has no real protection. 381 o If you need to secure UDP protocol exchange, it is suggested to verify 382 the authenticity of the reply, by using upper-layer security 383 mechanisms like DNSSEC (note that we cannot use IPsec with anycast). 385 o For many of the existing protocols, we cannot perform sanity checks 386 using IP source address address. More specifically, for UDP DNS 387 replies against queries to anycast address, it is not recommended to 388 check source address, based on RFC2181 section 4.1. 390 5.2. Use of TCP with anycast 392 We cannot simply use anycast for TCP exchanges, as we identify a TCP 393 connection by using address/port pair for the source/destination node. 394 It is desired to implement some of the following, to enable the use of 395 IPv6 anycast in TCP. Note, however, security requirement is rather 396 complicated for the following protocol modifications. 398 o Define a TCP option which lets us to switch peer's address from IPv6 399 anycast address, to IPv6 unicast address. There are couple of 400 proposals in the past. 402 o Define an additional connection setup protocol that resolves IPv6 403 unicast address from IPv6 anycast address. We first resolve IPv6 404 unicast address using the new protocol, and then, make a TCP 405 connection using the IPv6 unicast address. IPv6 node information 406 query/reply [Crawford, 2002] could be used for this. 408 5.3. Use of SCTP with Anycast 410 SCTP [Stewart, 2000] is a bit more interesting. An SCTP endpoint is 411 defined as: 413 The logical sender/receiver of SCTP packets. 414 On a multi-homed host, an SCTP endpoint is represented to its 415 peers as a combination of a set of eligible destination transport 416 addresses to which SCTP packets can be sent and a set of eligible 417 source transport addresses from which SCTP packets can be received. 418 All transport addresses used by an SCTP endpoint must use the same 419 port number, but can use multiple IP addresses. 421 Therefore, it is legal to send packets to a unicast address of an SCTP 422 peer endpoint, as long as the SCTP peer endpoint replies using a unicast 423 address which is part of the association. PP In summary, anycast should 424 work with SCTP, as long as the SCTP endpoint contains a valid unicast 425 address. 427 6. Summary 429 The draft tried to diagnose the limitation in currntly-specified IPv6 430 anycast, and explored couple of ways to extend its use. Some of the 431 proposed changes affects IPv6 anycast in general, some are useful in 432 certain use of IPv6 anycast. To take advantage of anycast addresses, 433 protocol designers would need to diagnose their requirements to anycast 434 address, and introduce some of the tricks described in the draft. 436 Use of IPsec with anycast address still needs a great amount of 437 analysis. 439 7. Security consideration 441 The document should introduce no new security issues. 443 When we use an anycast address to discover a server and then switch to 444 unicast adddress for the server, upper-layer protocols need to make sure 445 that the two addresses actually belong to the same node. Otherwise, 446 there could be a chance for malicious nodes to hijack the communciation. 447 One possible way to achieve this is to use public-key based 448 authentication in the upper-layer protocol. 450 For secure anycast operation, we may need to enable security mechanisms 451 in other protocols. For example, if we were to inject /128 routes from 452 end hosts by using a routing protocol, we may need to configure the 453 routing protocol to exchange routes securely, to prevent malicious 454 parties from injecting bogus routes. 456 References 458 Hinden, 1998. 459 R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in 460 RFC2373 (July 1998). ftp://ftp.isi.edu/in-notes/rfc2373.txt. 462 Partridge, 1993. 463 C. Partridge, T. Mendez, and W. Milliken, "Host Anycasting Service" in 464 RFC1546 (November 1993). ftp://ftp.isi.edu/in-notes/rfc1546.txt. 466 Hardie, 2002. 467 T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast 468 Addresses" in RFC3258 (April 2002). ftp://ftp.isi.edu/in- 469 notes/rfc3258.txt. 471 Ohta, 2000. 472 Masataka Ohta, "Root Name Servers with Inter Domain Anycast Addresses" 473 in draft-ietf-dnsop-ohta-shared-root-server-00.txt (July 2000). work in 474 progress material. 476 Haberman, 2001. 477 B. Haberman and D. Thaler, "Host-based Anycast using MLD" in draft- 478 haberman-ipngwg-host-anycast-00.txt (February 2001). work in progress 479 material. 481 Rockell, 2000. 482 Rob Rockell and Bob Fink, "6Bone Backbone Routing Guidelines" in RFC2772 483 (February 2000). ftp://ftp.isi.edu/in-notes/rfc2772.txt. 485 Elz, 1997. 486 R. Elz and R. Bush, "Clarifications to the DNS Specification" in RFC2181 487 (July 1997). ftp://ftp.isi.edu/in-notes/rfc2181.txt. 489 Sollins, 1992. 490 K. Sollins, "The TFTP Protocol (Revision 2)" in RFC1350 (July 1992). 491 ftp://ftp.isi.edu/in-notes/rfc1350.txt. 493 Crawford, 2002. 494 Matt Crawford, "IPv6 Node Information Queries" in draft-ietf-ipngwg- 495 icmp-name-lookups-09.txt (May 2002). work in progress material. 497 Stewart, 2000. 498 R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, 499 I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Stream Control 500 Transmission Protocol" in RFC2960 (October 2000). ftp://ftp.isi.edu/in- 501 notes/rfc2960.txt. 503 Change history 505 individual submission, 00 -> 01 506 Improve security considerations section. Remove an invalid use of 507 home address option from UDP section. Improve wording on IPsec. 509 individual submission, 01 -> 02 510 Split sections for current status analysis, and future protocol 511 design suggestions. 513 02 -> 00 514 Distinguish RFC2373 anycast and BGP anycast. Ettikan's new 515 address. 517 00 -> 01 518 Reflect IESG comments. BGP anycast is now called "pseudo anycast" 519 for clarity. SCTP section contributed by John Loughney. 521 Authors' addresses 523 Jun-ichiro itojun HAGINO 524 Research Laboratory, Internet Initiative Japan Inc. 525 Takebashi Yasuda Bldg., 526 3-13 Kanda Nishiki-cho, 527 Chiyoda-ku,Tokyo 101-0054, JAPAN 528 Tel: +81-3-5259-6350 529 Fax: +81-3-5259-6351 530 Email: itojun@iijlab.net 532 Ettikan Kandasamy Karupiah 533 ASG Penang & Shannon Operations, 534 Intel Microelectronis (M) Sdn. Bhd., 535 Bayan Lepas Free Trade Zone III, 536 Penang, Malaysia. 537 Tel: +60-4-859-2591 538 Fax: +60-4-859-7899 539 Email: ettikan.kandasamy.karuppiah@intel.com