Free from Using Zone Identifier for IPv6 Link-Local Address
draft-kitamura-ipv6-zoneid-free-00

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
               <draft-kitamura-ipv6-zoneid-free-00.txt>

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:

       <Address>%<Zone ID> representation is quite different from
       traditional <Address> only representation (without %<Zone ID>).

   Since <IP address> 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 %<Zone ID>) affects to too many
   things. It is almost impossible to modify huge number of existing
   communication applications to accept <Address>%<Zone ID>
   representation

   Also, new specifications are required to handle <Address>%<Zone ID>
   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
   "%<Zone ID>" 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) |
      +===============================+=====================+
      |   <Link-Local_Address_A>      |     <Zone-ID_X>     |
      +-------------------------------+---------------------+
      |   <Link-Local_Address_B>      |     <Zone-ID_Y>     |
      +-------------------------------+---------------------+
      |   ..........                  |     ....            |
      +-------------------------------+---------------------+

   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 "%<Zone ID>" to their arguments.

      ------------------------------------------------------------
      > ping6 <Link-Local_Address_A>%<Zone-ID_X>
      > ping6 <Link-Local_Address_B>%<Zone-ID_Y>

      > ssh   <Link-Local_Address_A>%<Zone-ID_X>
      > ssh   <Link-Local_Address_B>%<Zone-ID_Y>
      ------------------------------------------------------------
           Fig. 1 Current Communication Style with %<Zone ID>

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 "%<Zone ID>" to arguments of the following
   applications, and the goals are archived.

      ------------------------------------------------------------
      > fill_route_cache_entry <Link-Local_Address_A> <Zone-ID_X>
      > fill_route_cache_entry <Link-Local_Address_B> <Zone-ID_Y>

      > ping6 <Link-Local_Address_A>
      > ping6 <Link-Local_Address_B>

      > ssh   <Link-Local_Address_A>
      > ssh   <Link-Local_Address_B>
      ------------------------------------------------------------

                Fig. 2 Newly Designed Communication Style
                     without %<Zone ID>  (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 <Link-Local_Address_A>
      > ping6 <Link-Local_Address_B>

      > ssh   <Link-Local_Address_A>
      > ssh   <Link-Local_Address_B>
      ------------------------------------------------------------

                Fig. 3 Newly Designed Communication Style
                   without %<Zone ID>  (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]