idnits 2.17.1 draft-ietf-tsvwg-behave-requirements-update-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4787, updated by this document, for RFC5378 checks: 2005-01-13) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 18, 2016) is 3014 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG R. Penno 3 Internet-Draft Cisco 4 Updates: 4787, 5382, 5508 (if approved) S. Perreault 5 Intended status: Best Current Practice Jive Communications 6 Expires: July 21, 2016 M. Boucadair, Ed. 7 Orange 8 S. Sivakumar 9 Cisco 10 K. Naito 11 NTT 12 January 18, 2016 14 Network Address Translation (NAT) Behavioral Requirements Updates 15 draft-ietf-tsvwg-behave-requirements-update-06 17 Abstract 19 This document clarifies and updates several requirements of RFC4787, 20 RFC5382 and RFC5508 based on operational and development experience. 21 The focus of this document is NAT44. 23 This document updates RFC4787, RFC5382 and RFC5508. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 21, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. TCP Session Tracking . . . . . . . . . . . . . . . . . . . . 3 75 2.1. TCP Transitory Connection Idle-Timeout . . . . . . . . . 5 76 2.2. TCP RST . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. Port Overlapping Behavior . . . . . . . . . . . . . . . . . . 5 78 4. Address Pooling Paired (APP) . . . . . . . . . . . . . . . . 6 79 5. EIM Protocol Independence . . . . . . . . . . . . . . . . . . 6 80 6. EIF Protocol Independence . . . . . . . . . . . . . . . . . . 7 81 7. EIF Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 7 82 7.1. Outbound Mapping Refresh and Error Packets . . . . . . . 8 83 8. Port Parity . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 9. Port Randomization . . . . . . . . . . . . . . . . . . . . . 8 85 10. IP Identification (IP ID) . . . . . . . . . . . . . . . . . . 9 86 11. ICMP Query Mappings Timeout . . . . . . . . . . . . . . . . . 9 87 12. Hairpinning Support for ICMP Packets . . . . . . . . . . . . 9 88 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 89 14. Security Considerations . . . . . . . . . . . . . . . . . . . 9 90 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 91 15.1. Normative References . . . . . . . . . . . . . . . . . . 10 92 15.2. Informative References . . . . . . . . . . . . . . . . . 11 93 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 94 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 97 1. Introduction 99 [RFC4787], [RFC5382] and [RFC5508] greatly advanced Network Address 100 Translation (NAT) interoperability and conformance. Operational 101 experience gained through widespread deployment and evolution of NAT 102 indicates that some areas of the original documents need further 103 clarification or updates. This document provides such clarifications 104 and updates. 106 1.1. Scope 108 The goal of this document is to clarify and update the set of 109 requirements listed in [RFC4787], [RFC5382] and [RFC5508]. The 110 document focuses exclusively on NAT44. 112 The scope of this document has been set so that it does not create 113 new requirements beyond those specified in the documents cited above. 115 Carrier-Grade NAT (CGN) related requirements are defined in 116 [RFC6888]. 118 1.2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 The reader is assumed to be familiar with the terminology defined in: 125 [RFC2663],[RFC4787],[RFC5382], and [RFC5508]. 127 In this document, the term "NAT" refers to both "Basic NAT" and 128 "Network Address/Port Translator (NAPT)" (see Section 3 of 129 [RFC4787]). As a reminder, Basic NAT and NAPT are two variations of 130 traditional NAT, in that translation in Basic NAT is limited to IP 131 addresses alone, whereas translation in NAPT is extended to include 132 IP address and Transport identifier (such as TCP/UDP port or ICMP 133 query ID) (refer to Section 2 of [RFC3022]). 135 2. TCP Session Tracking 137 [RFC5382] specifies TCP timers associated with various connection 138 states but does not specify the TCP state machine a NAT44 should 139 follow as a basis to apply such timers. 141 Update: The TCP state machine depicted in Figure 1, adapted from 142 [RFC6146], SHOULD be implemented by a NAT for TCP session tracking 143 purposes. 145 +----------------------------+ 146 | | 147 V | 148 +------+ Client | 149 |CLOSED|-----SYN------+ | 150 +------+ | | 151 ^ | | 152 |TCP_TRANS T.O. | | 153 | V | 154 +-------+ +-------+ | 155 | TRANS | | INIT | | 156 +-------+ +-------+ | 157 | ^ | | 158 data pkt | | | 159 | Server/Client RST | | 160 | TCP_EST T.O. | | 161 V | Server SYN | 162 +--------------+ | | 163 | ESTABLISHED |<---------+ | 164 +--------------+ | 165 | | | 166 Client FIN Server FIN | 167 | | | 168 V V | 169 +---------+ +----------+ | 170 | C FIN | | S FIN | | 171 | RCV | | RCV | | 172 +---------+ +----------+ | 173 | | | 174 Server FIN Client FIN TCP_TRANS 175 | | T.O. 176 V V | 177 +----------------------+ | 178 | C FIN + S FIN RCV |-----------------+ 179 +----------------------+ 180 Legend: 181 * Messages sent or received from the server are 182 prefixed with "Server". 183 * Messages sent or received from the client are 184 prefixed with "Client". 185 * "C" means "Client-side" 186 * "S" means "Server-side". 187 * TCP_EST T.O: refers to the established connection 188 idle timeout as defined in [RFC5382]. 189 * TCP_TRANS T.O: refers to the transitory connection 190 idle timeout as defined in [RFC5382]. 192 Figure 1: Simplified version of the TCP State Machine 194 2.1. TCP Transitory Connection Idle-Timeout 196 The transitory connection idle-timeout is defined as the minimum time 197 a TCP connection in the partially open or closing phases must remain 198 idle before the NAT considers the associated session a candidate for 199 removal (REQ-5 of [RFC5382]). But [RFC5382] does not clearly state 200 whether these can be configured separately. 202 Clarification: This document clarifies that a NAT SHOULD provide 203 different configurable parameters for configuring the open and 204 closing idle timeouts. 206 To accommodate deployments that consider a partially open timeout 207 of 4 minutes as being excessive from a security standpoint, a NAT 208 MAY allow the configured timeout to be less than 4 minutes. 209 However, a minimum default transitory connection idle-timeout of 4 210 minutes is RECOMMENDED. 212 2.2. TCP RST 214 [RFC5382] leaves the handling of TCP RST packets unspecified. 216 Update: This document adopts a similar default behavior as in 217 [RFC6146]. Concretely, when the NAT receives a TCP RST matching 218 an existing mapping, it MUST translate the packet according the 219 NAT mapping entry. Moreover, the NAT SHOULD wait for 4 minutes 220 before deleting the session and removing any state associated with 221 it if no packets are received during that 4 minutes timeout. 223 Admittedly, the NAT has to verify whether received TCP RST packets 224 belong to a connection. This verification check is required to 225 avoid off-path attacks. 227 If the NAT removes immediately the NAT mapping upon receipt of a 228 TCP RST message, stale connections may be maintained by endpoints 229 if the first RST message is lost between the NAT and the 230 recipient. 232 3. Port Overlapping Behavior 234 REQ-1 from [RFC4787] and REQ-1 from [RFC5382] specify a specific port 235 overlapping behavior; that is the external IP address and port can be 236 reused for connections originating from the same internal source IP 237 address and port irrespective of the destination. This is known as 238 endpoint-independent mapping (EIM). 240 Update: This document clarifies that this port overlapping behavior 241 may be extended to connections originating from different internal 242 source IP addresses and ports as long as their destinations are 243 different. 245 The following mechanism MAY be implemented by a NAT: 247 If destination addresses and ports are different for outgoing 248 connections started by local clients, a NAT MAY assign the same 249 external port as the source ports for the connections. The 250 port overlapping mechanism manages mappings between external 251 packets and internal packets by looking at and storing their 252 5-tuple (protocol, source address, source port, destination 253 address, destination port). 255 This enables concurrent use of a single NAT external port for 256 multiple transport sessions, which allows a NAT to successfully 257 process packets in an IP address resource limited network (e.g., 258 deployment with high address space multiplicative factor (refer to 259 Appendix B. of [RFC6269])). 261 4. Address Pooling Paired (APP) 263 The Address Pooling Paired (APP) behavior for a NAT was recommended 264 in REQ-2 from [RFC4787], but the behavior when an external IPv4 runs 265 out of ports was left undefined. 267 Clarification: This document clarifies that if APP is enabled, new 268 sessions from a host that already has a mapping associated with an 269 external IP that ran out of ports SHOULD be dropped. A 270 configuration parameter MAY be provided to allow a NAT to starting 271 using ports from another external IP address when the one that 272 anchored the APP mapping ran out of ports. Tweaking this 273 configuration parameter is a trade-off between service continuity 274 and APP strict enforcement. Note, this behavior is sometimes 275 referred as 'soft-APP'. 277 As a reminder, the recommendation for the particular case of a CGN 278 is that an implementation must use the same external IP address 279 mapping for all sessions associated with the same internal IP 280 address, be they TCP, UDP, ICMP, something else, or a mix of 281 different protocols [RFC6888]. 283 Update: This behavior SHOULD apply also for TCP. 285 5. EIM Protocol Independence 287 REQ-1 from [RFC4787] and REQ-1 from [RFC5382] do not specify whether 288 EIM are protocol-dependent or protocol-independent. For example, if 289 an outbound TCP SYN creates a mapping, it is left undefined whether 290 outbound UDP packets can reuse such mapping. 292 Update: EIM mappings SHOULD be protocol-dependent. A configuration 293 parameter MAY be provided to allow protocols that multiplex TCP 294 and UDP over the same source IP address and port number to use a 295 single mapping. The default value of this configuration parameter 296 MUST be protocol-dependent EIM. 298 This update is compliant with the stateful NAT64 [RFC6146] that 299 clearly specifies three binding information bases (TCP, UDP, 300 ICMP). 302 6. EIF Protocol Independence 304 REQ-8 from [RFC4787] and REQ-3 from [RFC5382] do not specify whether 305 EIF mappings are protocol-independent or protocol-dependent . For 306 example, if an outbound TCP SYN creates a mapping, it is left 307 undefined whether inbound UDP packets matching that mapping should be 308 accepted or rejected. 310 Update: EIF filtering SHOULD be protocol-dependent. A configuration 311 parameter MAY be provided to make it protocol-independent. The 312 default value of this configuration parameter MUST be protocol- 313 dependent EIF. 315 This behavior is aligned with the update in Section 5. 317 Applications that can be transported over a variety of transport 318 protocols and/or support transport fall back schemes won't 319 experience connectivity failures if the NAT is configured with 320 protocol-independent EIM and protocol-independent EIF. 322 7. EIF Mapping Refresh 324 The NAT mapping Refresh direction may have a "NAT Inbound refresh 325 behavior" of "True" according to REQ-6 from [RFC4787], but [RFC4787] 326 does not clarify how this behavior applies to EIF mappings. The 327 issue in question is whether inbound packets that match an EIF 328 mapping but do not create a new session due to a security policy 329 should refresh the mapping timer. 331 Clarification: This document clarifies that even when a NAT has an 332 inbound refresh behavior set to 'TRUE', such packets SHOULD NOT 333 refresh the mapping. Otherwise a simple attack of a packet every 334 2 minutes can keep the mapping indefinitely. 336 Update: This behavior SHOULD apply also for TCP. 338 7.1. Outbound Mapping Refresh and Error Packets 340 Update: In the case of NAT outbound refresh behavior, ICMP Errors or 341 TCP RST outbound packets, sent as response to inbound packets, 342 SHOULD NOT refresh the mapping. 344 8. Port Parity 346 Update: A NAT MAY disable port parity preservation for all dynamic 347 mappings. Nevertheless, A NAT SHOULD support means to explicitly 348 request to preserve port parity (e.g., [I-D.ietf-pcp-port-set]). 350 Note: According to [RFC6887], dynamic mappings are said to be 351 dynamic in the sense that they are created on demand, either 352 implicitly or explicitly: 354 1. Implicit dynamic mappings refer to mappings that are created 355 as a side effect of traffic such as an outgoing TCP SYN or 356 outgoing UDP packet. Implicit dynamic mappings usually have a 357 finite lifetime, though this lifetime is generally not known 358 to the client using them. 360 2. Explicit dynamic mappings refer to mappings that are created 361 as a result, for example, of explicit Port Control Protocol 362 (PCP) MAP and PEER requests. Explicit dynamic mappings have a 363 finite lifetime, and this lifetime is communicated to the 364 client. 366 9. Port Randomization 368 Update: A NAT SHOULD follow the recommendations specified in 369 Section 4 of [RFC6056], especially: 371 "A NAPT that does not implement port preservation [RFC4787] 372 [RFC5382] SHOULD obfuscate selection of the ephemeral port of a 373 packet when it is changed during translation of that packet. A 374 NAPT that does implement port preservation SHOULD obfuscate the 375 ephemeral port of a packet only if the port must be changed as 376 a result of the port being already in use for some other 377 session. A NAPT that performs parity preservation and that 378 must change the ephemeral port during translation of a packet 379 SHOULD obfuscate the ephemeral ports. The algorithms described 380 in this document could be easily adapted such that the parity 381 is preserved (i.e., force the lowest order bit of the resulting 382 port number to 0 or 1 according to whether even or odd parity 383 is desired)." 385 10. IP Identification (IP ID) 387 Update: A NAT SHOULD handle the Identification field of translated 388 IPv4 packets as specified in Section 5.3.1 of [RFC6864]. 390 11. ICMP Query Mappings Timeout 392 Section 3.1 of [RFC5508] specifies that ICMP Query Mappings are to be 393 maintained by a NAT. However, the specification doesn't discuss 394 Query Mapping timeout values. Section 3.2 of [RFC5508] only 395 discusses ICMP Query Session Timeouts. 397 Update: ICMP Query Mappings MAY be deleted once the last session 398 using the mapping is deleted. 400 12. Hairpinning Support for ICMP Packets 402 REQ-7 from [RFC5508] specifies that a NAT enforcing 'Basic NAT' must 403 support traversal of hairpinned ICMP Query sessions. 405 Clarification: This implicitly means that address mappings from 406 external address to internal address (similar to Endpoint 407 Independent Filters) must be maintained to allow inbound ICMP 408 Query sessions. If an ICMP Query is received on an external 409 address, a NAT can then translate to an internal IP. 411 REQ-7 from [RFC5508] specifies that all NATs must support the 412 traversal of hairpinned ICMP Error messages. 414 Clarification: This behavior requires a NAT to maintain address 415 mappings from external IP address to internal IP address in 416 addition to the ICMP Query Mappings described in Section 3.1 of 417 [RFC5508]. 419 13. IANA Considerations 421 This document does not require any IANA action. 423 14. Security Considerations 425 NAT behavioral considerations are discussed in [RFC4787], [RFC5382], 426 and [RFC5508]. 428 Because some of the clarifications and updates (e.g., Section 2) are 429 inspired from NAT64, the security considerations discussed in 430 Section 5 of [RFC6146] apply also for this specification. 432 The update in Section 3 allows for an optimized NAT resource usage. 433 In order to avoid service disruption, the NAT MUST invoke this 434 functionality only if packets are to be sen to distinct destination 435 addresses. 437 Some of the updates (e.g., Section 7, Section 9, and Section 11) 438 allow for an increased security compared to [RFC4787], [RFC5382], and 439 [RFC5508]. Particularly: 441 o The updates in Section 7 and Section 11 prevent an illegitimate 442 node to maintain mappings activated in the NAT while these 443 mappings should be cleared. 445 o Port randomization (Section 9) complicates tracking hosts located 446 behind a NAT. 448 Section 4 and Section 12 propose updates that increase the 449 serviceability of a host located behind a NAT. These updates do not 450 introduce any additional security concerns to [RFC4787], [RFC5382], 451 and [RFC5508]. 453 The updates in Section 5 and Section 6 allow for a better NAT 454 transparency from an application standpoint. Hosts which require a 455 restricted filtering behavior should enable security-dedicated 456 features (e.g., access control list (ACL)) either locally or by 457 soliciting a dedicated security device (e.g., firewall). 459 The update in Section 8 induces security concerns that are specific 460 to the protocol used to interact with the NAT. For example, if PCP 461 is used to explicitly request parity preservation for a given 462 mapping, the security considerations discussed in [RFC6887] should be 463 taken into account. 465 The update in Section 10 may have undesired effects on the 466 performance of the NAT in environments in which fragmentation is 467 massively experienced. Such issue may be used as an attack vector 468 against NATs. 470 15. References 472 15.1. Normative References 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, 476 DOI 10.17487/RFC2119, March 1997, 477 . 479 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 480 Translation (NAT) Behavioral Requirements for Unicast 481 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 482 2007, . 484 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 485 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 486 RFC 5382, DOI 10.17487/RFC5382, October 2008, 487 . 489 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 490 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 491 DOI 10.17487/RFC5508, April 2009, 492 . 494 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 495 Protocol Port Randomization", BCP 156, RFC 6056, 496 DOI 10.17487/RFC6056, January 2011, 497 . 499 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 500 NAT64: Network Address and Protocol Translation from IPv6 501 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 502 April 2011, . 504 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 505 RFC 6864, DOI 10.17487/RFC6864, February 2013, 506 . 508 15.2. Informative References 510 [I-D.ietf-pcp-port-set] 511 Qiong, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, 512 T., and S. Perreault, "Port Control Protocol (PCP) 513 Extension for Port Set Allocation", draft-ietf-pcp-port- 514 set-13 (work in progress), October 2015. 516 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 517 Translator (NAT) Terminology and Considerations", 518 RFC 2663, DOI 10.17487/RFC2663, August 1999, 519 . 521 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 522 Address Translator (Traditional NAT)", RFC 3022, 523 DOI 10.17487/RFC3022, January 2001, 524 . 526 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 527 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 528 DOI 10.17487/RFC6269, June 2011, 529 . 531 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 532 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 533 DOI 10.17487/RFC6887, April 2013, 534 . 536 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 537 A., and H. Ashida, "Common Requirements for Carrier-Grade 538 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 539 April 2013, . 541 Acknowledgements 543 Thanks to Dan Wing, Suresh Kumar, Mayuresh Bakshi, Rajesh Mohan, Lars 544 Eggert, Gorry Fairhurst, Brandon Williams, and David Black for their 545 review and discussion. 547 Contributors 549 The following individual contributed text to the document: 551 Sarat Kamiset, Insieme Networks, United States 553 Authors' Addresses 555 Reinaldo Penno 556 Cisco Systems, Inc. 557 170 West Tasman Drive 558 San Jose, California 95134 559 USA 561 Email: repenno@cisco.com 563 Simon Perreault 564 Jive Communications 565 Canada 567 Email: sperreault@jive.com 568 Mohamed Boucadair (editor) 569 Orange 570 Rennes 35000 571 France 573 Email: mohamed.boucadair@orange.com 575 Senthil Sivakumar 576 Cisco Systems, Inc. 577 United States 579 Email: ssenthil@cisco.com 581 Kengo Naito 582 NTT 583 Tokyo 584 Japan 586 Email: k.naito@nttv6.jp