idnits 2.17.1 draft-ietf-6man-text-addr-representation-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (January 14, 2010) is 5213 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) == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: Standards Track M. Kawashima 5 Expires: July 18, 2010 NEC AccessTechnica, Ltd. 6 January 14, 2010 8 A Recommendation for IPv6 Address Text Representation 9 draft-ietf-6man-text-addr-representation-04 11 Abstract 13 As IPv6 network grows, there will be more engineers and also non- 14 engineers who will have the need to use an IPv6 address in text. 15 While the IPv6 address architecture RFC 4291 section 2.2 depicts a 16 flexible model for text representation of an IPv6 address, this 17 flexibility has been causing problems for operators, system 18 engineers, and users. This document will describe the problems that 19 a flexible text representation has been causing. This document also 20 recommends a canonical representation format that best avoids 21 confusion. It is expected that the canonical format is followed by 22 humans and systems when representing IPv6 addresses as text, but all 23 implementations must accept and be able to handle any legitimate 24 RFC4291 format. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on July 18, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 2. Text Representation Flexibility of RFC4291 . . . . . . . . . . 4 69 2.1. Leading Zeros in a 16 Bit Field . . . . . . . . . . . . . 4 70 2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5 71 2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 5 72 3. Problems Encountered with the Flexible Model . . . . . . . . . 6 73 3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6 75 3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6 76 3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6 77 3.1.4. Searching for an Address in a Network Diagram . . . . 7 78 3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7 79 3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7 80 3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7 81 3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 7 82 3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8 83 3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8 84 3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8 85 3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8 86 3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8 87 3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 8 88 3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9 89 3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9 90 3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9 91 3.4.2. Preference in Documentation . . . . . . . . . . . . . 9 92 3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 9 93 4. A Recommendation for IPv6 Text Representation . . . . . . . . 9 94 4.1. Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10 95 4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 96 4.2.1. Shorten As Much As Possible . . . . . . . . . . . . . 10 97 4.2.2. Handling One 16 Bit 0 Field . . . . . . . . . . . . . 10 98 4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10 99 4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 10 100 5. Text Representation of Special Addresses . . . . . . . . . . . 10 101 6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11 102 7. Prefix Representation . . . . . . . . . . . . . . . . . . . . 11 103 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 105 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 106 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 108 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 109 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 110 Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 13 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 113 1. Introduction 115 A single IPv6 address can be text represented in many ways. Examples 116 are shown below. 118 2001:db8:0:0:1:0:0:1 120 2001:0db8:0:0:1:0:0:1 122 2001:db8::1:0:0:1 124 2001:db8::0:1:0:0:1 126 2001:0db8::1:0:0:1 128 2001:db8:0:0:1::1 130 2001:db8:0000:0:1::1 132 2001:DB8:0:0:1::1 134 All the above point to the same IPv6 address. This flexibility has 135 caused many problems for operators, systems engineers, and customers. 136 The problems will be noted in Section 3. Also, a canonical 137 representation format to avoid problems will be introduced in 138 Section 4. 140 1.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 2. Text Representation Flexibility of RFC4291 148 Examples of flexibility in Section 2.2 of [RFC4291] are described 149 below. 151 2.1. Leading Zeros in a 16 Bit Field 153 'It is not necessary to write the leading zeros in an individual 154 field.' 156 In other words, it is also not necessary to omit leading zeros. This 157 means that, it is possible to select from such as the following 158 example. The final 16 bit field is different, but all these 159 addresses mean the same. 161 2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001 163 2001:db8:aaaa:bbbb:cccc:dddd:eeee:001 165 2001:db8:aaaa:bbbb:cccc:dddd:eeee:01 167 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1 169 2.2. Zero Compression 171 'A special syntax is available to compress the zeros. The use of 172 "::" indicates one or more groups of 16 bits of zeros.' 174 It is possible to select whether or not to omit just one 16 bits of 175 zeros. 177 2001:db8:aaaa:bbbb:cccc:dddd::1 179 2001:db8:aaaa:bbbb:cccc:dddd:0:1 181 In case where there are more than one zero fields, there is a choice 182 of how many fields can be shortened. Examples follow. 184 2001:db8:0:0:0::1 186 2001:db8:0:0::1 188 2001:db8:0::1 190 2001:db8::1 192 In addition, [RFC4291] in section 2.2 notes, 194 'The "::" can only appear once in an address.' 196 This gives a choice on where, in a single address to compress the 197 zero. Examples are shown below. 199 2001:db8::aaaa:0:0:1 201 2001:db8:0:0:aaaa::1 203 2.3. Uppercase or Lowercase 205 [RFC4291] does not mention about preference of uppercase or 206 lowercase. Various flavors are shown below. 208 2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa 210 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA 212 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa 214 3. Problems Encountered with the Flexible Model 216 3.1. Searching 218 3.1.1. General Summary 220 A search of an IPv6 address if conducted through a UNIX system is 221 usually case sensitive and extended options to allow for regular 222 expression use will come in handy. However, there are many 223 applications in the Internet today that do not provide this 224 capability. When searching for an IPv6 address in such systems, the 225 system engineer will have to try each and every possibility to search 226 for an address. This has critical impacts especially when trying to 227 deploy IPv6 over an enterprise network. 229 3.1.2. Searching Spreadsheets and Text Files 231 Spreadsheet applications and text editors on GUI systems, rarely have 232 the ability to search for a text using regular expression. Moreover, 233 there are many non-engineers (who are not aware of case sensitivity 234 and regular expression use) that use these application to manage IP 235 addresses. This has worked quite well with IPv4 since text 236 representation in IPv4 has very little flexibility. There is no 237 incentive to encourage these non-engineers to change their tool or 238 learn regular expression when they decide to go dual-stack. If the 239 entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was 240 conducted as 2001:db8:0:0:1::1, this will show a result of no match. 241 One example where this will cause problem is, when the search is 242 being conducted to assign a new address from a pool, and a check was 243 being done to see if it was not in use. This may cause problems to 244 the end-hosts or end-users. This type of address management is very 245 often seen in enterprise networks and also in ISPs. 247 3.1.3. Searching with Whois 249 The "whois" utility is used by a wide range of people today. When a 250 record is set to a database, one will likely check the output to see 251 if the entry is correct. If an entity was recorded as 2001:db8::/48, 252 but the whois output showed 2001:0db8:0000::/48, most non-engineers 253 would think that their input was wrong, and will likely retry several 254 times or make a frustrated call to the database hostmaster. If there 255 was a need to register the same address on different systems, and 256 each system showed a different text representation, this would 257 confuse people even more. Although this document focuses on 258 addresses rather than prefixes, this is worth mentioning since 259 problems encountered are mostly equal. 261 3.1.4. Searching for an Address in a Network Diagram 263 Network diagrams and blue-prints contain IP addresses as allocated to 264 system devices. In times of trouble shooting, there may be a need to 265 search through a diagram to find the point of failure (for example, 266 if a traceroute stopped at 2001:db8::1, one would search the diagram 267 for that address). This is a technique quite often in use in 268 enterprise networks and managed services. Again, the different 269 flavors of text representation will result in a time-consuming 270 search, leading to longer MTTR in times of trouble. 272 3.2. Parsing and Modifying 274 3.2.1. General Summary 276 With all the possible text representation ways, each application must 277 include a module, object, link, etc. to a function that will parse 278 IPv6 addresses in a manner that no matter how it is represented, they 279 will mean the same address. This is not too much a problem if the 280 output is to be just 'read' or 'managed' by a network engineer. 281 However, many system engineers who integrate complex computer systems 282 to corporate customers will have difficulties finding that their 283 favorite tool will not have this function, or will encounter 284 difficulties such as having to rewrite their macro's or scripts for 285 their 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. Sometimes, logging for critical systems is done 294 by mirroring the same traffic to two different systems. Care must be 295 taken that no matter what the log output is, the logs should be 296 parsed so they will mean the same. 298 3.2.3. Auditing: Case 1 300 When a router or any other network appliance machine configuration is 301 audited, there are many methods to compare the configuration 302 information of a node. Sometimes, auditing will be done by just 303 comparing the changes made each day. In this case, if configuration 304 was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000: 305 0000:0000:0000:0001 just because the new engineer on the block felt 306 it was better, a simple diff will tell you that a different address 307 was configured. If this was done on a wide scale network, people 308 will be focusing on 'why the extra zeros were put in' instead of 309 doing any real auditing. Lots of tools are just plain 'diff's that 310 do not take into account address representation rules. 312 3.2.4. Auditing: Case 2 314 Node configurations will be matched against an information system 315 that manages IP addresses. If output notation is different, there 316 will need to be a script that is implemented to cover for this. The 317 result of an SNMP GET operation, converted to text and compared to a 318 textual address written by a human is highly unlikely to match on 319 first try. 321 3.2.5. Verification 323 Some protocols require certain data fields to be verified. One 324 example of this is X.509 certificates. If an IPv6 address field in a 325 certificate was incorrectly verified by converting it to text and 326 making a simple textual comparison to some other address, the 327 certificate may be mistakenly shown as being invalid due to a 328 difference in text representation methods. 330 3.2.6. Unexpected Modifying 332 Sometimes, a system will take an address and modify it as a 333 convenience. For example, a system may take an input of 334 2001:0db8:0::1 and make the output 2001:db8::1. If the zeros were 335 input for a reason, the outcome may be somewhat unexpected. 337 3.3. Operating 339 3.3.1. General Summary 341 When an operator sets an IPv6 address of a system as 2001:db8:0:0:1: 342 0:0:1, the system may take the address and show the configuration 343 result as 2001:DB8::1:0:0:1. Someone familiar with IPv6 address 344 representation will know that the right address is set, but not 345 everyone may understand this. 347 3.3.2. Customer Calls 349 When a customer calls to inquire about a suspected outage, IPv6 350 address representation should be handled with care. Not all 351 customers are engineers nor have the same skill in IPv6 technology. 352 The network operations center will have to take extra steps to 353 humanly parse the address to avoid having to explain to the customers 354 that 2001:db8:0:1::1 is the same as 2001:db8::1:0:0:0:1. This is one 355 thing that will never happen in IPv4 because IPv4 address cannot be 356 abbreviated. 358 3.3.3. Abuse 360 Network abuse is reported along with the abusing IP address. This 361 'reporting' could take any shape or form of the flexible model. A 362 team that handles network abuse must be able to tell the difference 363 between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the 364 placement of the "::" will result in a critical situation. A system 365 that handles these incidents should be able to handle any type of 366 input and parse it in a correct manner. Also, incidents are reported 367 over the phone. It is unnecessary to report if the letter is an 368 uppercase or lowercase. However, when a letter is spelled uppercase, 369 people tend to clarify that it is uppercase, which is unnecessary 370 information. 372 3.4. Other Minor Problems 374 3.4.1. Changing Platforms 376 When an engineer decides to change the platform of a running service, 377 the same code may not work as expected due to the difference in IPv6 378 address text representation. Usually, a change in a platform (e.g. 379 Unix to Windows, Cisco to Juniper) will result in a major change of 380 code anyway, but flexibility in address representation will increase 381 the work load. 383 3.4.2. Preference in Documentation 385 A document that is edited by more than one author, may become harder 386 to read. 388 3.4.3. Legibility 390 Capital case D and 0 can be quite often misread. Capital B and 8 can 391 also be misread. 393 4. A Recommendation for IPv6 Text Representation 395 A recommendation for a canonical text representation format of IPv6 396 addresses is presented in this section. The recommendation in this 397 document is one that, complies fully with [RFC4291], is implemented 398 by various operating systems, and is human friendly. The 399 recommendation in this document SHOULD be followed by systems when 400 generating an address to represent as text, but all implementations 401 MUST accept any legitimate [RFC4291] format. It is advised that 402 humans also follow these recommendations when spelling an address. 404 4.1. Handling Leading Zeros in a 16 Bit Field 406 Leading zeros should be chopped for human legibility and easier 407 searching. Also, a single 16 bit 0000 field should be represented as 408 just 0. 410 4.2. "::" Usage 412 4.2.1. Shorten As Much As Possible 414 The use of "::" should be used to its maximum capability (i.e. 2001: 415 db8::0:1 is not considered as clean representation). 417 4.2.2. Handling One 16 Bit 0 Field 419 "::" should not be used to shorten just one 16 bit 0 field for it 420 would tend to mislead that there are more than one 16 bit field that 421 is shortened. 423 4.2.3. Choice in Placement of "::" 425 When there is an alternative choice in the placement of a "::", the 426 longest run of consecutive 16 bit 0 fields should be shortened (i.e. 427 latter is shortened in 2001:0:0:1:0:0:0:1). When the length of the 428 consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1), 429 the former is shortened. This is consistent with many current 430 implementations. One idea to avoid any confusion, is for the 431 operator to not use 16 bit field 0 in the first 64 bits. By nature 432 IPv6 addresses are usually assigned or allocated to end-users from a 433 prefix of 32 bits or longer (typically 48 bits or longer). 435 4.3. Lower Case 437 Recent implementations tend to represent IPv6 address as lower case. 438 It is better to use lower case to avoid problems such as described in 439 section 3.3.3 and 3.4.3. 441 5. Text Representation of Special Addresses 443 Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and 444 IPv4-translatable addresses [I-D.ietf-behave-address-format] have 445 IPv4 addresses embedded in the low-order 32 bits of the address. 446 These addresses have special representation that may mix hexadecimal 447 and dot decimal notations. The decimal notation may be used only for 448 the last 32 bits of the address. For these addresses, mixed notation 449 is recommended if the following condition is met: The address can be 450 distinguished as having IPv4 addresses embedded in the lower 32 bits 451 solely from the address field through the use of a well known prefix. 452 If it is known by some external method that a given prefix includes 453 an IPv4 address, it MAY be represented as mixed notation. Tools that 454 provide options to specify prefixes that is (or is not) to be 455 represented as mixed notation may be useful. 457 The text representation method noted in Section 4 should be applied 458 for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of 459 0:0:0:0:0:ffff:192.0.2.1). 461 6. Notes on Combining IPv6 Addresses with Port Numbers 463 When IPv6 addresses and port numbers are represented in text combined 464 together, there are many different ways to do so. Examples are shown 465 below. 467 o [2001:db8::1]:80 469 o 2001:db8::1:80 471 o 2001:db8::1.80 473 o 2001:db8::1 port 80 475 o 2001:db8::1p80 477 o 2001:db8::1#80 479 The situation is not much different in IPv4, but the most ambiguous 480 case with IPv6 is the second bullet. This is due to the "::"usage in 481 IPv6 addresses. This style is not recommended for its ambiguity. 482 The [] style as expressed in [RFC3986] should be employed, and is the 483 default unless otherwise specified. Other styles are acceptable when 484 there is exactly one style for the given context and cross-platform 485 portability does not become an issue. 487 7. Prefix Representation 489 Problems with prefixes are just the same as problems encountered with 490 addresses. Text representation method of IPv6 prefixes should be no 491 different from that of IPv6 addresses. 493 8. Conclusion 495 The recommended format of text representing an IPv6 address is 496 summarized as follows. 498 (1) omit leading zeros in a 16 bit field 500 (2) when using "::", shorten consecutive zero fields to their 501 maximum extent (leave no zero fields behind). 503 (3) "::" used where shortens address the most 505 (4) "::" used in the former part in case of a tie breaker 507 (5) do not shorten one 16 bit 0 field, but always shorten when 508 there are two or more consecutive 16 bit 0 fields 510 (6) use lower case 512 Hints for developers are written in the Appendix section. 514 9. Security Considerations 516 None. 518 10. IANA Considerations 520 None. 522 11. Acknowledgements 524 The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami, 525 Toshimitsu Matsuura for their generous and helpful comments in kick 526 starting this document. We also would like to thank Brian Carpenter, 527 Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler, 528 Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki 529 Vatiainen ,Dan Wing for their input. Also a very special thanks to 530 Ron Bonica, Fred Baker, Brian Haberman, Robert Hinden, Jari Arkko, 531 and Kurt Lindqvist for their support in bringing this document to the 532 light of IETF working groups. 534 12. References 536 12.1. Normative References 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119, March 1997. 541 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 542 Architecture", RFC 4291, February 2006. 544 12.2. Informative References 546 [I-D.ietf-behave-address-format] 547 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 548 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 549 draft-ietf-behave-address-format-03 (work in progress), 550 December 2009. 552 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 553 Resource Identifier (URI): Generic Syntax", STD 66, 554 RFC 3986, January 2005. 556 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 557 Castro, "Application Aspects of IPv6 Transition", 558 RFC 4038, March 2005. 560 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 561 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 562 March 2008. 564 Appendix A. For Developers 566 We recommend that developers use display routines that conform to 567 these rules. For example, the usage of getnameinfo() with flags 568 argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output, 569 except for the special addresses notes in Section 5. The function 570 inet_ntop() of FreeBSD7.0 is a good C code reference, but should not 571 be called directly. See [RFC4038] for details. 573 Authors' Addresses 575 Seiichi Kawamura 576 NEC BIGLOBE, Ltd. 577 14-22, Shibaura 4-chome 578 Minatoku, Tokyo 108-8558 579 JAPAN 581 Phone: +81 3 3798 6085 582 Email: kawamucho@mesh.ad.jp 584 Masanobu Kawashima 585 NEC AccessTechnica, Ltd. 586 800, Shimomata 587 Kakegawa-shi, Shizuoka 436-8501 588 JAPAN 590 Phone: +81 537 23 9655 591 Email: kawashimam@necat.nec.co.jp