idnits 2.17.1 draft-kawamura-ipv6-text-representation-03.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.ii 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 (June 12, 2009) is 5429 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3493' is defined on line 524, but no explicit reference was found in the text == Unused Reference: 'RFC5156' is defined on line 536, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2765 (Obsoleted by RFC 6145) -- Obsolete informational reference (is this intentional?): RFC 5156 (Obsoleted by RFC 6890) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Kawamura 3 Internet-Draft NEC BIGLOBE, Ltd. 4 Intended status: Informational M. Kawashima 5 Expires: December 14, 2009 NEC AccessTechnica, Ltd. 6 June 12, 2009 8 A Recommendation for IPv6 Address Text Representation 9 draft-kawamura-ipv6-text-representation-03 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 December 14, 2009. 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 customers. This document will describe the problems 54 that a flexible text representation has been causing. This document 55 also 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 generating an address to represent as text, 58 but all implementations must accept any legitimate RFC4291 format. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. Text Representation Flexibility of RFC4291 . . . . . . . . . . 4 65 2.1. Leading Zeros in a 16 Bit Field . . . . . . . . . . . . . 4 66 2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5 67 2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 5 68 3. Problems Encountered with the Flexible Model . . . . . . . . . 6 69 3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6 71 3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6 72 3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6 73 3.1.4. Searching for an Address in a Network Diagram . . . . 7 74 3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7 75 3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7 76 3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.2.3. Auditing. Case 1 . . . . . . . . . . . . . . . . . . . 8 78 3.2.4. Auditing. Case 2 . . . . . . . . . . . . . . . . . . . 8 79 3.2.5. Unexpected Modifying . . . . . . . . . . . . . . . . . 8 80 3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8 81 3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8 82 3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 8 83 3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9 84 3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9 85 3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9 86 3.4.2. Preference in Documentation . . . . . . . . . . . . . 9 87 3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 9 88 4. A Recommendation for IPv6 Text Representation . . . . . . . . 9 89 4.1. Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10 90 4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 91 4.2.1. shorten as much as possible . . . . . . . . . . . . . 10 92 4.2.2. One 16 bit 0 Field . . . . . . . . . . . . . . . . . . 10 93 4.2.3. When "::" Can Be Used Twice . . . . . . . . . . . . . 10 94 4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 10 95 5. Text Representation of Special Addresses . . . . . . . . . . . 10 96 6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11 97 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 102 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 103 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 104 Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 13 105 Appendix B. Prefix Issues . . . . . . . . . . . . . . . . . . . . 13 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 108 1. Introduction 110 A single IPv6 address can be text represented in many ways. Examples 111 are shown below. 113 2001:db8:0:0:1:0:0:1 115 2001:0db8:0:0:1:0:0:1 117 2001:db8::1:0:0:1 119 2001:db8::0:1:0:0:1 121 2001:0db8::1:0:0:1 123 2001:db8:0:0:1::1 125 2001:db8:0000:0:1::1 127 2001:DB8:0:0:1::1 129 All the above point to the same IPv6 address. This flexibility has 130 caused many problems for operators, systems engineers, and customers. 131 The problems will be noted in Section 3. Also, a canonical 132 representation format to avoid problems will be introduced in 133 Section 4. 135 1.1. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 2. Text Representation Flexibility of RFC4291 143 Examples of flexibility in Section 2.2 of [RFC4291] are described 144 below. 146 2.1. Leading Zeros in a 16 Bit Field 148 'It is not necessary to write the leading zeros in an individual 149 field.' 151 In other words, it is also not necessary to omit leading zeros. This 152 means that, it is possible to select from such as the following 153 example. The final 16 bit field is different, but all these 154 addresses mean the same. 156 2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001 158 2001:db8:aaaa:bbbb:cccc:dddd:eeee:001 160 2001:db8:aaaa:bbbb:cccc:dddd:eeee:01 162 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1 164 2.2. Zero Compression 166 'A special syntax is available to compress the zeros. The use of 167 "::" indicates one or more groups of 16 bits of zeros.' 169 It is possible to select whether or not to omit just one 16 bits of 170 zeros. 172 2001:db8:aaaa:bbbb:cccc:dddd::1 174 2001:db8:aaaa:bbbb:cccc:dddd:0:1 176 In case where there are more than one zero fields, there is a choice 177 of how many fields can be shortened. Examples follow. 179 2001:db8:0:0:0::1 181 2001:db8:0:0::1 183 2001:db8:0::1 185 2001:db8::1 187 In addition, [RFC4291] in section 2.2 notes, 189 'The "::" can only appear once in an address.' 191 This gives a choice on where, in a single address to compress the 192 zero. Examples are shown below. 194 2001:db8::aaaa:0:0:1 196 2001:db8:0:0:aaaa::1 198 2.3. Uppercase or Lowercase 200 [RFC4291] does not mention about preference of uppercase or 201 lowercase. Various flavors are shown below. 203 2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa 205 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA 207 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa 209 ... more combinations 211 3. Problems Encountered with the Flexible Model 213 3.1. Searching 215 3.1.1. General Summary 217 A search of an IPv6 address if conducted through a UNIX system is 218 usually case sensitive and extended options to allow for regular 219 expression use will come in handy. However, there are many 220 applications in the internet today that do not provide this 221 capability. When searching for an IPv6 address in such systems, the 222 system engineer will have to try each and every possibility to search 223 for an address. This has critical impacts especially when trying to 224 deploy IPv6 over an enterprise network. 226 3.1.2. Searching Spreadsheets and Text Files 228 Spreadsheet applications and text editors on GUI systems, rarely have 229 the ability to search for a text using regular expression. Moreover, 230 there are many non-engineers (who are not aware of case sensitivity 231 and regular expression use) that use these application to manage IP 232 addresses. This has worked quite well with IPv4 since text 233 representation in IPv4 has very little flexibility. There is no 234 incentive to encourage these non-engineers to change their tool or 235 learn regular expression when they decide to go dual-stack. If the 236 entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was 237 conducted as 2001:db8:0:0:1::1, this will show a result of no match. 238 One example where this will cause problem is, when the search is 239 being conducted to assign a new address from a pool, and a check was 240 being done to see if it was not in use. This may cause problems to 241 the end-hosts or end-users. This type of address management is very 242 often seen in enterprise network s and also in ISPs. 244 3.1.3. Searching with Whois 246 The whois utility is used by a wide range of people today. When a 247 record is set to the whois database, one will likely check the output 248 to see if the entry is correct. If a entity was recorded as 2001: 249 db8::/48, but the whois output showed 2001:0db8:0000::/48, most non- 250 engineers would think that their input was wrong, and will likely 251 retry several times or make a frustrated call to the database 252 hostmaster. If there was a need to register the same address on 253 different systems, and each system showed a different text 254 representation, this would confuse people even more. Although this 255 document focuses on addresses rather than prefixes, this is worth 256 mentioning since problems encountered are mostly equal. 258 3.1.4. Searching for an Address in a Network Diagram 260 Network diagrams and blue-prints contain IP addresses of systems. In 261 times of trouble shooting, there may be a need to search through a 262 diagram to find the point of failure (for example, if a traceroute 263 stopped at 2001:db8::1, one would search the diagram for that 264 address). This is a technique quite often in use in enterprise 265 networks and managed services. Again, the different flavors of text 266 representation will result in a time-consuming search, leading to 267 longer MTTR in times of trouble. 269 3.2. Parsing and Modifying 271 3.2.1. General Summary 273 With all the possible text representation ways, each application must 274 include a module, object, link, etc. to a function that will parse 275 IPv6 addresses in a manner that no matter how it is represented, they 276 will mean the same address. This is not too much a problem if the 277 output is to be just 'read' or 'managed' by a network engineer. 278 However, many system engineers who integrate complex computer systems 279 to corporate customers will have difficulties finding that their 280 favorite tool will not have this function, or will encounter 281 difficulties such as having to rewrite their macro's or scripts for 282 their customers. It must be noted that each additional line of a 283 program will result in increased development fees that will be 284 charged to the customers. 286 3.2.2. Logging 288 If an application were to output a log summary that represented the 289 address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444), 290 the output would be highly unreadable compared to the IPv4 output. 291 The address would have to be parsed and reformed to make it useful 292 for human reading. This will result in additional code on the 293 applications which will result in extra fees charged to the 294 customers. Sometimes, logging for critical systems is done by 295 mirroring the same traffic to two different systems. Care must be 296 taken that no matter what the log output is, the logs should be 297 parsed so they will mean the same. 299 3.2.3. Auditing. Case 1 301 When a router or any other network appliance machine configuration is 302 audited, there are many methods to compare the configuration 303 information of a node. Sometimes, auditing will be done by just 304 comparing the changes made each day. In this case, if configuration 305 was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000: 306 0000:0000:0000:0001 just because the new engineer on the block felt 307 it was better, a simple diff will tell you that a different address 308 was configured. If this was done on a wide scale network, people 309 will be focusing on 'why the extra zeros were put in' instead of 310 doing any real auditing. Lots of tools are just plain 'diff's that 311 do not take into account address representation rules. 313 3.2.4. Auditing. Case 2 315 Node configurations will be matched against a information system that 316 manages IP addresses. If output notation is different, there will 317 need to be a script that is implemented to cover for this. An SNMP 318 GET of an interface address and text representation in a humanly 319 written text file is highly unlikely to match on first try. 321 3.2.5. Unexpected Modifying 323 Sometimes, a system will take an address and modify it as a 324 convenience. For example, a system may take an input of 325 2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some 326 RIR databases). If the zeros were input for a reason, the outcome 327 may be somewhat unexpected. 329 3.3. Operating 331 3.3.1. General Summary 333 When an operator sets an IPv6 address of a system as 2001:db8:0:0:1: 334 0:0:1, the system may take the address and show the configuration 335 result as 2001:DB8::1:0:0:1. A distinguished engineer will know that 336 the right address is set, but an operator, or a customer that is 337 communicating with the operator to solve a problem, is usually not as 338 distinguished as we would like. Again, the extra load in checking 339 that the IP address is the same as was intended, will result in fees 340 that will be charged to the customers. 342 3.3.2. Customer Calls 344 When a customer calls to inquire about a suspected outage, IPv6 345 address representation should be handled with care. Not all 346 customers are engineers nor have the same skill in IPv6 technology. 348 The NOC will have to take extra steps to humanly parse the address to 349 avoid having to explain to the customers that 2001:db8:0:1::1 is the 350 same as 2001:db8::1:0:0:0:1. This is one thing that will never 351 happen in IPv4 because IPv4 address cannot be abbreviated. 353 3.3.3. Abuse 355 Network abuse is reported along with the abusing IP address. This 356 'reporting' could take any shape or form of the flexible model. A 357 team that handles network abuse must be able to tell the difference 358 between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the 359 placement of the "::" will result in a critical situation. A system 360 that handles these incidents should be able to handle any type of 361 input and parse it in a correct manner. Also, incidents are reported 362 over the phone. It is unnecessary to report if the letter is an 363 uppercase or lowercase. However, when a letter is spelled uppercase, 364 people tend to clarify that it is uppercase, which is unnecessary 365 information. 367 3.4. Other Minor Problems 369 3.4.1. Changing Platforms 371 When an engineer decides to change the platform of a running service, 372 the same code may not work as expected due to the difference in IPv6 373 address text representation. Usually, a change in a platform (e.g. 374 Unix to Windows, Cisco to Juniper) will result in a major change of 375 code, but flexibility in address representation will increase the 376 work load which will again, result in fees that will be charged to 377 the customers, and also longer down time of systems. 379 3.4.2. Preference in Documentation 381 A document that is edited by more than one author, may become harder 382 to read. 384 3.4.3. Legibility 386 Capital case D and 0 can be quite often misread. Capital B and 8 can 387 also be misread. 389 4. A Recommendation for IPv6 Text Representation 391 A recommendation for a canonical text representation format of IPv6 392 addresses is presented in this section. The recommendation in this 393 document is one that, complies fully with [RFC4291], is implemented 394 by various operating systems, and is human friendly. The 395 recommendation in this document SHOULD be followed by humans and 396 systems when generating an address to represent as text, but all 397 implementations MUST accept any legitimate [RFC4291] format. 399 4.1. Handling Leading Zeros in a 16 Bit Field 401 Leading zeros should be chopped for human legibility and easier 402 searching. Also, a single 16 bit 0000 field should be represented as 403 just 0. Place holder zeros are often cause of misreading. 405 4.2. "::" Usage 407 4.2.1. shorten as much as possible 409 The use of "::" should be used to its maximum capability (i.e. 2001: 410 db8::0:1 is not very clean). 412 4.2.2. One 16 bit 0 Field 414 "::" should not be used to shorten just one 16 bit 0 field for it 415 would tend to mislead that there are more than one 16 bit field that 416 is shortened. 418 4.2.3. When "::" Can Be Used Twice 420 When cases where it is possible to use "::" in two or more different 421 sections of an address, implementation to shorten the side with 422 longer 16 bit 0 fields are more common (i.e. latter is shortened in 423 2001:0:0:1:0:0:0:1). When the length of 16 bit 0 fields are equal 424 (i.e. 2001:db8:0:0:1:0:0:1), the former is usually shortened. One 425 idea to avoid any confusion, is for the operator to not use 16 bit 426 field 0 in the first 64 bits. By nature IPv6 addresses are usually 427 assigned or allocated to end-users as longer than 32 bits (typically 428 48 bits or longer). 430 4.3. Lower Case 432 Recent implementations tend to represent IPv6 address as lower case. 433 It is better to use lower case to avoid problems such as described in 434 section 3.3.3 and 3.4.3. 436 5. Text Representation of Special Addresses 438 IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and IPv4-translated 439 addresses [RFC2765] have IPv4 addresses embedded in the low-order 32 440 bits of the address. These addresses have special representation 441 that may combine hexadecimal and decimal notations. In cases where 442 there is a choice of whether to express the address as fully 443 hexadecimal or hexadecimal and decimal combined, decimal notations 444 should be used. The text representation method noted in Section 4 445 should be applied for the leading hexadecimal part (i.e. ::ffff: 446 192.0.2.1 instead of 0:0:0:0:0:ffff:192.0.2.1). 448 6. Notes on Combining IPv6 Addresses with Port Numbers 450 When IPv6 addresses and port numbers are represented in text combined 451 together, there seems to be many different ways to do so. Examples 452 are shown below. 454 o [2001:db8::1]:80 456 o 2001:db8::1:80 458 o 2001:db8::1.80 460 o 2001:db8::1 port 80 462 o 2001:db8::1p80 464 o 2001:db8::1#80 466 The situation is not much different in IPv4, but the most ambiguous 467 case with IPv6 is the second bullet. This is due to the "::"usage in 468 IPv6 addresses. This style is not recommended for its ambiguity. 469 The most common case is the [] style as expressed in [RFC3986]. 471 7. Conclusion 473 The recommended format of text representing an IPv6 address is 474 summarized as follows. 476 (1) omit leading zeros 478 (2) "::" used to their maximum extent whenever possible 480 (3) "::" used where shortens address the most 482 (4) "::" used in the former part in case of a tie breaker 484 (5) do not shorten one 16 bit 0 field, but always shorten when 485 there are two or more consecutive 16 bit 0 fields 486 (6) use lower case 488 Hints for developers are written in the Appendix section. 490 8. Security Considerations 492 None. 494 9. IANA Considerations 496 None. 498 10. Acknowledgements 500 The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami, 501 Toshimitsu Matsuura for their generous and helpful comments in kick 502 starting this document. We also would like to thank Brian Carpenter, 503 Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler, 504 Brian Haley, Suresh Krishnan, Jerry Huang for their input. Also a 505 very special thanks to Ron Bonica, Fred Baker, Brian Haberman, Robert 506 Hinden, Jari Arkko, and Kurt Lindqvist for their support in bringing 507 this document to the light of IETF working groups. 509 11. References 511 11.1. Normative References 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, March 1997. 516 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 517 Architecture", RFC 4291, February 2006. 519 11.2. Informative References 521 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 522 (SIIT)", RFC 2765, February 2000. 524 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 525 Stevens, "Basic Socket Interface Extensions for IPv6", 526 RFC 3493, February 2003. 528 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 529 Resource Identifier (URI): Generic Syntax", STD 66, 530 RFC 3986, January 2005. 532 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 533 Castro, "Application Aspects of IPv6 Transition", 534 RFC 4038, March 2005. 536 [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 537 April 2008. 539 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 540 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 541 March 2008. 543 Appendix A. For Developers 545 We recommend that developers use display routines that conform to 546 these rules. For example, the usage of getnameinfo() with flags 547 argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output. 548 The function inet_ntop() of FreeBSD7.0 is a good C code reference, 549 but should not be called directly. See [RFC4038] for details. 551 Appendix B. Prefix Issues 553 Problems with prefixes are just the same as problems encountered with 554 addresses. Text representation method of IPv6 prefixes should be no 555 different from that of IPv6 addresses. 557 Authors' Addresses 559 Seiichi Kawamura 560 NEC BIGLOBE, Ltd. 561 14-22, Shibaura 4-chome 562 Minatoku, Tokyo 108-8558 563 JAPAN 565 Phone: +81 3 3798 6085 566 Email: kawamucho@mesh.ad.jp 567 Masanobu Kawashima 568 NEC AccessTechnica, Ltd. 569 800, Shimomata 570 Kakegawa-shi, Shizuoka 436-8501 571 JAPAN 573 Phone: +81 537 23 9655 574 Email: kawashimam@necat.nec.co.jp