Network Working Group H. Kitamura Internet-Draft NEC Corporation Intended status: Standards Track S. Ata Expires: January 2014 Osaka City University M. Murata Osaka University July 10, 2013 Free from Using Zone Identifier for IPv6 Link-Local Address Abstract This document describes how end users can become free from using zone identifiers for IPv6 link-local addresses. When users deal with IPv6 link-local addresses, it is thought that it is mandatory thing to specify accompanied zone identifiers. For end users, however, it is troublesome and nuisance thing to do it. Because it is very hard for normal end users to find appropriate zone identifiers for this purpose. From another viewpoint, the usage of IPv6 link-local addresses accompanied with zone identifiers is quite different from the usage of traditional global addresses, many problems are caused and new specifications are required to fix these problems. This document explores and describes a new mechanism that makes end users free from using zone identifiers for IPv6 link-local addresses. In order to achieve the mechanism, a new notion table that is called "Link-Local Route Cache" is introduced. This method is upper compatible with the current mechanism and harmless to the existing communications. By adding small improvement to neighbor discovery implementation, "Link-Local Route Cache" is easily implemented. With this method, end users will be released from using nuisance zone identifiers for IPv6 link-local addresses. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that H. Kitamura Expires January 2014 [Page 1] Internet Draft Free from Using Zone ID other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 2013. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Analysis of the problems of using Zone ID . . . . . . . . . . . 4 3. Reconsideration of Zone-ID specification from the beginning . . 6 3.1. Why we need Zone-ID? . . . . . . . . . . . . . . . . . . . . 6 3.2. Which actual process requires Zone ID information? . . . . . 6 4. Design of "Link-Local Route Cache" . . . . . . . . . . . . . . 7 4.1. Manual cache entry fill type . . . . . . . . . . . . . . . 8 4.2. Automatic cache entry fill type . . . . . . . . . . . . . . 8 5. Implementation of "Link-Local Route Cache" (Neighbor Discovery Extensions) . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 H. Kitamura Expires January 2014 [Page 2] Internet Draft Free from Using Zone ID 1. Introduction This document describes how end users can become free from using zone identifiers for IPv6 link-local addresses. When users deal with IPv6 link-local addresses, it is thought that it is mandatory thing to specify accompanied zone identifiers. For end users, however, it is troublesome and nuisance thing to do it. Because it is very hard for normal end users to find appropriate zone identifiers for this purpose. From another viewpoint, the usage of IPv6 link-local addresses accompanied zone identifiers is quite different from the usage of traditional global addresses, many problems are caused and new specifications (such as [RFC6874]) are required to fix these problems. The problems of using zone identifiers (Zone IDs) are analyzed in the following section. This document explores and describes a new mechanism that makes end users free from using Zone IDs for IPv6 link-local addresses. In order to achieve the mechanism, a new notion table that is called "Link-Local Route Cache" is introduced. This method is upper compatible with the current mechanism and harmless to the existing communication. By adding small improvement to neighbor discovery implementation, "Link-Local Route Cache" is easily implemented. With this method, end users will be released from using nuisance zone identifiers for IPv6 link-local addresses. H. Kitamura Expires January 2014 [Page 3] Internet Draft Free from Using Zone ID 2. Analysis of the problems of using Zone ID In this section, problems of using Zone ID are analyzed and described. Problem 1: Zone ID is hard information to tell for normal end users. Current Zone ID specifications require end users to do hard works. For normal end users who do not have enough knowledge of their nodes' and network configuration, it is hard to know Zone IDs (names of their nodes' interfaces). Furthermore, it is too hard to find and tell which actual Zone ID is appropriate for their link- local communications. It is very nuisance for normal end users, and it will be almost impossible for them to specify appropriate Zone ID. Problem 2: Zone ID is node-local info. and cannot be shared with others. Zone ID is local and closed information to each node. Zone ID information used on a certain node is meaningless information for outside nodes. In other words, Zone ID information cannot be shared with outside nodes. Zone ID cannot be used for advertisement type information (e.g., printer or file folder sharing, DNS etc.). Command line operations that include Zone ID arguments also become local on one node. They cannot be reused on the other nodes. It means that "copy and paste" type operations will not work effectively for these command line operations. Problem 3: Zone ID depends on node's situation and will be changed. For an end user's node (e.g., Note PC) which has multiple interfaces (e.g., one is Ethernet, the other is Wireless LAN) and connects to the network via either of interfaces, used Zone IDs for communications with the same link-local address are not always the same. It depends on the node's situation which interface is used to connect the network. Even on the same node, this characteristic makes difficult to reuses command line operations that include Zone ID arguments. H. Kitamura Expires January 2014 [Page 4] Internet Draft Free from Using Zone ID Problem 4:
% representation is quite different from traditional
only representation (without %). Since is primitive information, it is used at various places everywhere of communication programs. - Command line arguments of communication applications. - "Address Bar" of Web browsers - Configuration files - Firewall filter - DNS server - in URI / URL - etc. This representation change (with %) affects to too many things. It is almost impossible to modify huge number of existing communication applications to accept
% representation Also, new specifications are required to handle
% representation. [RFC6874] specification is designed only for URI. In order to cover all environments, more specifications are required. Goals of this document are to make end users be released from using Zone ID and to provide environment that they do not have to attach "%" to their applications arguments. H. Kitamura Expires January 2014 [Page 5] Internet Draft Free from Using Zone ID 3. Reconsideration of Zone ID specification from the beginning As shown above, current Zone ID related specifications imply many problems. We may have some prejudice on Zone ID related specifications. In order to remove such prejudice, we have to reconsider Zone ID specification from the beginning. 3.1. Why we need zone ID? Under multiple interfaces environment, we cannot specify the destination only with Link-Local Address. Zone ID (interface) information is also necessary to specify the destination uniquely. This is true. We have to provide Zone ID (interface) information to Link-Local Address communications. Problems of the current specification should be located on the method how to provide Zone ID (interface) information to Link-Local Address communications. 3.2. Which actual process requires zone ID information? When receiving Link-Local packets, there are no difficulties. Zone ID (interface) is easily and naturally identified. When transmitting Link-Local packets, we meet a difficulty. Without Zone ID (interface) information, we cannot transmit a packet. There is one exception on transmitting Link-Local packets that can avoid this difficulty. When transmitting a Link-Local packet as a reply packet to a received Link-Local packet, there is no difficulty. Because which Zone ID (interface) should be used for the transmitting reply packet is shown by which interface is used at the corresponding received packet. Only when initially we transmit a Link-Local packet, we meet a difficulty. All of IP communications are started after L2 addresses are resolved by Neighbor Discovery operations. Therefore, initially transmitting operation can be concluded to transmitting NS (Neighbor Solicitation) packet operation and a difficulty is happened here. H. Kitamura Expires January 2014 [Page 6] Internet Draft Free from Using Zone ID 4. Design of "Link-Local Route Cache" In order to solve above described Zone ID related problems and achieve goals, we propose to introduce a new table called "Link- Local Route Cache". As table 1 shows, "Link-Local Route Cache" is composed of two types of members. One is "IPv6 Link-Local Address", and the other is "Interface (Zone ID)". Table 1 Link Local Route Cache: +-------------------------------+---------------------+ | IPv6 Link-Local Address | Interface (Zone ID) | +===============================+=====================+ | | | +-------------------------------+---------------------+ | | | +-------------------------------+---------------------+ | .......... | .... | +-------------------------------+---------------------+ When we transmit a packet, whose destination address is link-local one and listed on the Link-Local Route Cache, listed corresponding "Interface (Zone ID)" is used to transmit it. There are two types of method to fill entries of Link-Local Route Cache. One is "Manual fill type", and the other is "Automatic fill type". By introducing "Link-Local Route Cache", link-local applications' communication style is changed. Fig. 1 shows current communication style. Every applications are required to attach "%" to their arguments. ------------------------------------------------------------ > ping6 % > ping6 % > ssh % > ssh % ------------------------------------------------------------ Fig. 1 Current Communication Style with % H. Kitamura Expires January 2014 [Page 7] Internet Draft Free from Using Zone ID 4.1. Manual cache entry fill type Fig. 2 shows newly designed communication style that is achieved by "Manual fill type". Once route cache entries are filled manually, we do not have to attach "%" to arguments of the following applications, and the goals are archived. ------------------------------------------------------------ > fill_route_cache_entry > fill_route_cache_entry > ping6 > ping6 > ssh > ssh ------------------------------------------------------------ Fig. 2 Newly Designed Communication Style without % (manual fill type) 4.2. Automatic cache entry fill type Fig. 3 shows newly designed communication style that is achieved by "Automatic fill type". This is a kind of ideal communication style for end users, and the goals are archived. It is same to traditional global address communication style. ------------------------------------------------------------ > ping6 > ping6 > ssh > ssh ------------------------------------------------------------ Fig. 3 Newly Designed Communication Style without % (automatic fill type) In order to fill route cache entry automatically, new technical methods are required. They are described in the next section. H. Kitamura Expires January 2014 [Page 8] Internet Draft Free from Using Zone ID 5. Implementation of "Link-Local Route Cache" (Neighbor Discovery Extensions) As described in Section 3.2, only when initially we transmit a Link-Local packet, Interface (Zone ID) information is required. Initially packet transmitting operation can be concluded transmitting NS (Neighbor Solicitation) message operation. Therefore, "Link-Local Route Cache" implementation is tightly related with Neighbor Discovery operations and it is implemented by extending current Neighbor Discovery implementation. For Manual cache entry fill type operation, no special technique is required to implement. "Link-Local Route Cache" is implemented naturally and easily by extending current Neighbor Discovery implementation. For Automatic cache entry fill type operation, special techniques are required. They are described below. With current NS packet transmitting operation, single packet is transmitted via the designated interface. And, NA packet that is replied and received via the same interface is waited. When Interface (Zone ID) information of the Link-Local Route Cache entry is not filled, there is no designated interface. With current operation, we could not transmit NS packet. With this proposal, we extend this operation. We will send multiple NS packets via available all interfaces. And NA packet that is replied and received via either of interfaces that is used for transmitting the NS is waited. After a NA packet is received, the interface that is used for receiving the NA is registered to the corresponding Interface (Zone ID) entry of the Link-Local Route Cache. Table 2 NS Transmit Specification Comparison +--------------------+----------+--------------------------+ | Specification | # of NS | via Interface (Zone ID) | +====================+==========+==========================+ | Current | Single | designated one interface | +--------------------+----------+--------------------------+ | Proposed Extension | Multiple | available all interfaces | +--------------------+----------+--------------------------+ NS packet transmit specification comparison is shown at Table 2. By adding small improvement to neighbor discovery implementation, "Link-Local Route Cache" is easily implemented and the goals are archived. H. Kitamura Expires January 2014 [Page 9] Internet Draft Free from Using Zone ID 6. Security Considerations Since the "Link-Local Route Cache" is implemented by extending Neighbor Discovery operation and no new messages are introduced, Security Considerations of Neighbor Discovery [RFC4861] can be also applied to this document. 7. IANA Considerations This document does not require any resource assignments to IANA. Acknowledgment A part of this work is supported by the program: SCOPE (Strategic Information and Communications R&D Promotion Programme) operated by Ministry of Internal Affairs and Communications of JAPAN. References Normative References [RFC3513] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003 [RFC4007] S. Deering, B. Haberman, T. Jinmei, E. Nordmark and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, February 2005. [RFC4861] T. Narten, E. Nordmark, W. Simpson and H. Soliman, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 2007 [RFC6874] B. Carpenter, S. Cheshire and R. Hinden, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", RFC 6874, February 2013 Informative References [RFC3542] W. Stevens, M. Thomas, E. Nordmark and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003 [RFC5952] S. Kawamura and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010. H. Kitamura Expires January 2014 [Page 10] Internet Draft Free from Using Zone ID Authors' Addresses Hiroshi Kitamura Cloud System Research Laboratories, NEC Corporation (SC building 12F)1753, Shimonumabe, Nakahara-Ku, Kawasaki, Kanagawa 211-8666, JAPAN Phone: +81 44 431 7686 Fax: +81 44 431 7680 Email: kitamura@da.jp.nec.com Shingo Ata Graduate School of Engineering, Osaka City University 3-3-138, Sugimoto, Sumiyoshi-Ku, Osaka 558-8585, JAPAN Phone: +81 6 6605 2191 Fax: +81 6 6605 2191 Email: ata@info.eng.osaka-cu.ac.jp Masayuki Murata Graduate School of Information Science and Technology, Osaka Univ. 1-5 Yamadaoka, Suita, Osaka 565-0871, JAPAN Phone: +81 6 6879 4542 Fax: +81 6 6879 4544 Email: murata@ist.osaka-u.ac.jp H. Kitamura Expires January 2014 [Page 11]