idnits 2.17.1 draft-ietf-6man-text-addr-representation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2009) is 5302 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance Working Group S. Kawamura 3 Internet-Draft NEC BIGLOBE, Ltd. 4 Intended status: Informational M. Kawashima 5 Expires: April 21, 2010 NEC AccessTechnica, Ltd. 6 October 18, 2009 8 A Recommendation for IPv6 Address Text Representation 9 draft-ietf-6man-text-addr-representation-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 21, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 As IPv6 network grows, there will be more engineers and also non- 48 engineers who will have the need to use an IPv6 address in text. 50 While the IPv6 address architecture RFC 4291 section 2.2 depicts a 51 flexible model for text representation of an IPv6 address, this 52 flexibility has been causing problems for operators, system 53 engineers, and users. This document will describe the problems that 54 a flexible text representation has been causing. This document also 55 recommends a canonical representation format that best avoids 56 confusion. It is expected that the canonical format is followed by 57 humans and systems when representing IPv6 addresses as text, but all 58 implementations must accept and be able to handle any legitimate 59 RFC4291 format. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2. Text Representation Flexibility of RFC4291 . . . . . . . . . . 4 66 2.1. Leading Zeros in a 16 Bit Field . . . . . . . . . . . . . 4 67 2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5 68 2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 5 69 3. Problems Encountered with the Flexible Model . . . . . . . . . 6 70 3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6 72 3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6 73 3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6 74 3.1.4. Searching for an Address in a Network Diagram . . . . 7 75 3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7 76 3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7 77 3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7 78 3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 8 79 3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8 80 3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8 81 3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8 82 3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8 83 3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8 84 3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 9 85 3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9 86 3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9 87 3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9 88 3.4.2. Preference in Documentation . . . . . . . . . . . . . 9 89 3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 10 90 4. A Recommendation for IPv6 Text Representation . . . . . . . . 10 91 4.1. Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10 92 4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 93 4.2.1. Shorten As Much As Possible . . . . . . . . . . . . . 10 94 4.2.2. Handling One 16 Bit 0 Field . . . . . . . . . . . . . 10 95 4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10 96 4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 11 98 5. Text Representation of Special Addresses . . . . . . . . . . . 11 99 6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11 100 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 103 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 105 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 106 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 107 Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 13 108 Appendix B. Prefix Issues . . . . . . . . . . . . . . . . . . . . 13 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 111 1. Introduction 113 A single IPv6 address can be text represented in many ways. Examples 114 are shown below. 116 2001:db8:0:0:1:0:0:1 118 2001:0db8:0:0:1:0:0:1 120 2001:db8::1:0:0:1 122 2001:db8::0:1:0:0:1 124 2001:0db8::1:0:0:1 126 2001:db8:0:0:1::1 128 2001:db8:0000:0:1::1 130 2001:DB8:0:0:1::1 132 All the above point to the same IPv6 address. This flexibility has 133 caused many problems for operators, systems engineers, and customers. 134 The problems will be noted in Section 3. Also, a canonical 135 representation format to avoid problems will be introduced in 136 Section 4. 138 1.1. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 2. Text Representation Flexibility of RFC4291 146 Examples of flexibility in Section 2.2 of [RFC4291] are described 147 below. 149 2.1. Leading Zeros in a 16 Bit Field 151 'It is not necessary to write the leading zeros in an individual 152 field.' 154 In other words, it is also not necessary to omit leading zeros. This 155 means that, it is possible to select from such as the following 156 example. The final 16 bit field is different, but all these 157 addresses mean the same. 159 2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001 161 2001:db8:aaaa:bbbb:cccc:dddd:eeee:001 163 2001:db8:aaaa:bbbb:cccc:dddd:eeee:01 165 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1 167 2.2. Zero Compression 169 'A special syntax is available to compress the zeros. The use of 170 "::" indicates one or more groups of 16 bits of zeros.' 172 It is possible to select whether or not to omit just one 16 bits of 173 zeros. 175 2001:db8:aaaa:bbbb:cccc:dddd::1 177 2001:db8:aaaa:bbbb:cccc:dddd:0:1 179 In case where there are more than one zero fields, there is a choice 180 of how many fields can be shortened. Examples follow. 182 2001:db8:0:0:0::1 184 2001:db8:0:0::1 186 2001:db8:0::1 188 2001:db8::1 190 In addition, [RFC4291] in section 2.2 notes, 192 'The "::" can only appear once in an address.' 194 This gives a choice on where, in a single address to compress the 195 zero. Examples are shown below. 197 2001:db8::aaaa:0:0:1 199 2001:db8:0:0:aaaa::1 201 2.3. Uppercase or Lowercase 203 [RFC4291] does not mention about preference of uppercase or 204 lowercase. Various flavors are shown below. 206 2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa 208 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA 210 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa 212 3. Problems Encountered with the Flexible Model 214 3.1. Searching 216 3.1.1. General Summary 218 A search of an IPv6 address if conducted through a UNIX system is 219 usually case sensitive and extended options to allow for regular 220 expression use will come in handy. However, there are many 221 applications in the Internet today that do not provide this 222 capability. When searching for an IPv6 address in such systems, the 223 system engineer will have to try each and every possibility to search 224 for an address. This has critical impacts especially when trying to 225 deploy IPv6 over an enterprise network. 227 3.1.2. Searching Spreadsheets and Text Files 229 Spreadsheet applications and text editors on GUI systems, rarely have 230 the ability to search for a text using regular expression. Moreover, 231 there are many non-engineers (who are not aware of case sensitivity 232 and regular expression use) that use these application to manage IP 233 addresses. This has worked quite well with IPv4 since text 234 representation in IPv4 has very little flexibility. There is no 235 incentive to encourage these non-engineers to change their tool or 236 learn regular expression when they decide to go dual-stack. If the 237 entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was 238 conducted as 2001:db8:0:0:1::1, this will show a result of no match. 239 One example where this will cause problem is, when the search is 240 being conducted to assign a new address from a pool, and a check was 241 being done to see if it was not in use. This may cause problems to 242 the end-hosts or end-users. This type of address management is very 243 often seen in enterprise networks and also in ISPs. 245 3.1.3. Searching with Whois 247 The "whois" utility is used by a wide range of people today. When a 248 record is set to a database, one will likely check the output to see 249 if the entry is correct. If an entity was recorded as 2001:db8::/48, 250 but the whois output showed 2001:0db8:0000::/48, most non-engineers 251 would think that their input was wrong, and will likely retry several 252 times or make a frustrated call to the database hostmaster. If there 253 was a need to register the same address on different systems, and 254 each system showed a different text representation, this would 255 confuse people even more. Although this document focuses on 256 addresses rather than prefixes, this is worth mentioning since 257 problems encountered are mostly equal. 259 3.1.4. Searching for an Address in a Network Diagram 261 Network diagrams and blue-prints contain IP addresses as allocated to 262 system devices. In times of trouble shooting, there may be a need to 263 search through a diagram to find the point of failure (for example, 264 if a traceroute stopped at 2001:db8::1, one would search the diagram 265 for that address). This is a technique quite often in use in 266 enterprise networks and managed services. Again, the different 267 flavors of text representation will result in a time-consuming 268 search, leading to longer MTTR in times of trouble. 270 3.2. Parsing and Modifying 272 3.2.1. General Summary 274 With all the possible text representation ways, each application must 275 include a module, object, link, etc. to a function that will parse 276 IPv6 addresses in a manner that no matter how it is represented, they 277 will mean the same address. This is not too much a problem if the 278 output is to be just 'read' or 'managed' by a network engineer. 279 However, many system engineers who integrate complex computer systems 280 to corporate customers will have difficulties finding that their 281 favorite tool will not have this function, or will encounter 282 difficulties such as having to rewrite their macro's or scripts for 283 their customers. It must be noted that each additional line of a 284 program will result in increased development fees that will be 285 charged to the customers. 287 3.2.2. Logging 289 If an application were to output a log summary that represented the 290 address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444), 291 the output would be highly unreadable compared to the IPv4 output. 292 The address would have to be parsed and reformed to make it useful 293 for human reading. This will result in additional code on the 294 applications which will result in extra fees charged to the 295 customers. Sometimes, logging for critical systems is done by 296 mirroring the same traffic to two different systems. Care must be 297 taken that no matter what the log output is, the logs should be 298 parsed so they will mean the same. 300 3.2.3. Auditing: Case 1 302 When a router or any other network appliance machine configuration is 303 audited, there are many methods to compare the configuration 304 information of a node. Sometimes, auditing will be done by just 305 comparing the changes made each day. In this case, if configuration 306 was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000: 307 0000:0000:0000:0001 just because the new engineer on the block felt 308 it was better, a simple diff will tell you that a different address 309 was configured. If this was done on a wide scale network, people 310 will be focusing on 'why the extra zeros were put in' instead of 311 doing any real auditing. Lots of tools are just plain 'diff's that 312 do not take into account address representation rules. 314 3.2.4. Auditing: Case 2 316 Node configurations will be matched against an information system 317 that manages IP addresses. If output notation is different, there 318 will need to be a script that is implemented to cover for this. An 319 SNMP GET of an interface address and text representation in a humanly 320 written text file is highly unlikely to match on first try. 322 3.2.5. Verification 324 Some protocols require certain data fields to be verified. One 325 example of this is X.509 certificates. If an IPv6 address was 326 embedded in one of the fields in a certificate, and the verification 327 was done by just a simple textual comparison, the certificate may be 328 maistakenly shown as being invalid due to a difference in text 329 representation methods. 331 3.2.6. Unexpected Modifying 333 Sometimes, a system will take an address and modify it as a 334 convenience. For example, a system may take an input of 335 2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some 336 RIR databases). If the zeros were input for a reason, the outcome 337 may be somewhat unexpected. 339 3.3. Operating 341 3.3.1. General Summary 343 When an operator sets an IPv6 address of a system as 2001:db8:0:0:1: 344 0:0:1, the system may take the address and show the configuration 345 result as 2001:DB8::1:0:0:1. A distinguished engineer will know that 346 the right address is set, but an operator, or a customer that is 347 communicating with the operator to solve a problem, is usually not as 348 distinguished as we would like. Again, the extra load in checking 349 that the IP address is the same as was intended, will result in fees 350 that will be charged to the customers. 352 3.3.2. Customer Calls 354 When a customer calls to inquire about a suspected outage, IPv6 355 address representation should be handled with care. Not all 356 customers are engineers nor have the same skill in IPv6 technology. 357 The NOC will have to take extra steps to humanly parse the address to 358 avoid having to explain to the customers that 2001:db8:0:1::1 is the 359 same as 2001:db8::1:0:0:0:1. This is one thing that will never 360 happen in IPv4 because IPv4 address cannot be abbreviated. 362 3.3.3. Abuse 364 Network abuse is reported along with the abusing IP address. This 365 'reporting' could take any shape or form of the flexible model. A 366 team that handles network abuse must be able to tell the difference 367 between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the 368 placement of the "::" will result in a critical situation. A system 369 that handles these incidents should be able to handle any type of 370 input and parse it in a correct manner. Also, incidents are reported 371 over the phone. It is unnecessary to report if the letter is an 372 uppercase or lowercase. However, when a letter is spelled uppercase, 373 people tend to clarify that it is uppercase, which is unnecessary 374 information. 376 3.4. Other Minor Problems 378 3.4.1. Changing Platforms 380 When an engineer decides to change the platform of a running service, 381 the same code may not work as expected due to the difference in IPv6 382 address text representation. Usually, a change in a platform (e.g. 383 Unix to Windows, Cisco to Juniper) will result in a major change of 384 code, but flexibility in address representation will increase the 385 work load which will again, result in fees that will be charged to 386 the customers, and also longer down time of systems. 388 3.4.2. Preference in Documentation 390 A document that is edited by more than one author, may become harder 391 to read. 393 3.4.3. Legibility 395 Capital case D and 0 can be quite often misread. Capital B and 8 can 396 also be misread. 398 4. A Recommendation for IPv6 Text Representation 400 A recommendation for a canonical text representation format of IPv6 401 addresses is presented in this section. The recommendation in this 402 document is one that, complies fully with [RFC4291], is implemented 403 by various operating systems, and is human friendly. The 404 recommendation in this document SHOULD be followed by humans and 405 systems when generating an address to represent as text, but all 406 implementations MUST accept any legitimate [RFC4291] format. 408 4.1. Handling Leading Zeros in a 16 Bit Field 410 Leading zeros should be chopped for human legibility and easier 411 searching. Also, a single 16 bit 0000 field should be represented as 412 just 0. Place holder zeros are often cause of misreading. 414 4.2. "::" Usage 416 4.2.1. Shorten As Much As Possible 418 The use of "::" should be used to its maximum capability (i.e. 2001: 419 db8::0:1 is not considered as clean representation). 421 4.2.2. Handling One 16 Bit 0 Field 423 "::" should not be used to shorten just one 16 bit 0 field for it 424 would tend to mislead that there are more than one 16 bit field that 425 is shortened. 427 4.2.3. Choice in Placement of "::" 429 When there is an alternative choice in the placement of a "::", the 430 longest run of consecutive 16 bit 0 fields should be shortened (i.e. 431 latter is shortened in 2001:0:0:1:0:0:0:1). When the length of the 432 consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1), 433 the former is shortened. This is consistent with many current 434 implementations. One idea to avoid any confusion, is for the 435 operator to not use 16 bit field 0 in the first 64 bits. By nature 436 IPv6 addresses are usually assigned or allocated to end-users as 437 longer than 32 bits (typically 48 bits or longer). 439 4.3. Lower Case 441 Recent implementations tend to represent IPv6 address as lower case. 442 It is better to use lower case to avoid problems such as described in 443 section 3.3.3 and 3.4.3. 445 5. Text Representation of Special Addresses 447 Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and 448 IPv4-translated addresses [RFC2765] have IPv4 addresses embedded in 449 the low-order 32 bits of the address. These addresses have special 450 representation that may mix hexadecimal and decimal notations. In 451 cases where there is a choice of whether to express the address as 452 fully hexadecimal or hexadecimal and decimal mixed, and if the 453 address type can be distinguished as having IPv4 addresses embedded 454 in the lower 32 bits solely from the 128bits of the address field 455 itself, mixed notation is the better choice. However, there may be 456 situations where hexadecimal representation is chosen to meet certain 457 needs. Addressing those needs is out of the scope of this document. 458 The text representation method noted in Section 4 should be applied 459 for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of 460 0:0:0:0:0:ffff:192.0.2.1). 462 6. Notes on Combining IPv6 Addresses with Port Numbers 464 When IPv6 addresses and port numbers are represented in text combined 465 together, there seems to be many different ways to do so. Examples 466 are shown below. 468 o [2001:db8::1]:80 470 o 2001:db8::1:80 472 o 2001:db8::1.80 474 o 2001:db8::1 port 80 476 o 2001:db8::1p80 478 o 2001:db8::1#80 480 The situation is not much different in IPv4, but the most ambiguous 481 case with IPv6 is the second bullet. This is due to the "::"usage in 482 IPv6 addresses. This style is not recommended for its ambiguity. 483 The [] style as expressed in [RFC3986] is recommended. Other styles 484 are acceptable when cross-platform portability does not become an 485 issue. 487 7. Conclusion 489 The recommended format of text representing an IPv6 address is 490 summarized as follows. 492 (1) omit leading zeros in a 16 bit field 494 (2) when using "::", shorten consecutive zero fields to their 495 maximum extent (leave no zero fields behind). 497 (3) "::" used where shortens address the most 499 (4) "::" used in the former part in case of a tie breaker 501 (5) do not shorten one 16 bit 0 field, but always shorten when 502 there are two or more consecutive 16 bit 0 fields 504 (6) use lower case 506 Hints for developers are written in the Appendix section. 508 8. Security Considerations 510 None. 512 9. IANA Considerations 514 None. 516 10. Acknowledgements 518 The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami, 519 Toshimitsu Matsuura for their generous and helpful comments in kick 520 starting this document. We also would like to thank Brian Carpenter, 521 Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler, 522 Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki 523 Vatiainen for their input. Also a very special thanks to Ron Bonica, 524 Fred Baker, Brian Haberman, Robert Hinden, Jari Arkko, and Kurt 525 Lindqvist for their support in bringing this document to the light of 526 IETF working groups. 528 11. References 530 11.1. Normative References 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, March 1997. 535 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 536 Architecture", RFC 4291, February 2006. 538 11.2. Informative References 540 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 541 (SIIT)", RFC 2765, February 2000. 543 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 544 Resource Identifier (URI): Generic Syntax", STD 66, 545 RFC 3986, January 2005. 547 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 548 Castro, "Application Aspects of IPv6 Transition", 549 RFC 4038, March 2005. 551 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 552 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 553 March 2008. 555 Appendix A. For Developers 557 We recommend that developers use display routines that conform to 558 these rules. For example, the usage of getnameinfo() with flags 559 argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output, 560 except for the special addresses notes in Section 5. The function 561 inet_ntop() of FreeBSD7.0 is a good C code reference, but should not 562 be called directly. See [RFC4038] for details. 564 Appendix B. Prefix Issues 566 Problems with prefixes are just the same as problems encountered with 567 addresses. Text representation method of IPv6 prefixes should be no 568 different from that of IPv6 addresses. 570 Authors' Addresses 572 Seiichi Kawamura 573 NEC BIGLOBE, Ltd. 574 14-22, Shibaura 4-chome 575 Minatoku, Tokyo 108-8558 576 JAPAN 578 Phone: +81 3 3798 6085 579 Email: kawamucho@mesh.ad.jp 581 Masanobu Kawashima 582 NEC AccessTechnica, Ltd. 583 800, Shimomata 584 Kakegawa-shi, Shizuoka 436-8501 585 JAPAN 587 Phone: +81 537 23 9655 588 Email: kawashimam@necat.nec.co.jp