Skip to main content

Corresponding Auto Names for IPv6 Addresses
draft-kitamura-ipv6-auto-name-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Hiroshi Kitamura , Shingo Ata
Last updated 2011-10-24
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-kitamura-ipv6-auto-name-00
Internet Draft                                               H. Kitamura
<draft-kitamura-ipv6-auto-name-00.txt>                   NEC Corporation
                                                                  S. Ata
                                                   Osaka City University
Expires April 2012                                      October 24, 2011

             Corresponding Auto Names for IPv6 Addresses
                <draft-kitamura-ipv6-auto-name-00.txt>

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
   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 September 2011.

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.

H. Kitamura        Expires April 2012                           [Page 1]
Internet Draft     Corresponding Auto Names for IPv6

Abstract

   This document discusses notion and actual mechanisms of
   "Corresponding Auto Names" for IPv6 Addresses. With this mechanism,
   all IPv6 addresses (even if they are link-local scoped addresses)
   can obtain their own Names, and it will be able to use Names
   anywhere instead of IPv6 Addresses.

   IPv6 address is too long and complicated to remember, and it is
   very nuisance thing to type a literal IPv6 address manually as an
   argument of applications. Also, it is very difficult for human
   beings to tell which IPv6 address is set to which actual IPv6 node.
   In this sense, literal IPv6 address information can be called
   meaningless information for human beings.

   In order to solve above problems and to make the information
   meaningful, mechanisms called Corresponding Auto Names for IPv6
   addresses is introduced. They will become gentle information for
   human beings. By applying a simple naming rule to the Auto Names
   (e.g., use the same name-prefix for IPv6 addresses that are set to
   the same interface (node)), this will contribute to help people to
   understand which IPv6 address / Name indicates which actual IPv6
   node.

1. Introduction

   This document discusses notion and actual mechanisms of
   "Corresponding Auto Names" for IPv6 Addresses.

   IPv6 address is too long and complicated to remember, and it is
   very nuisance thing to type a literal IPv6 address manually as an
   argument of applications.

   Furthermore, it is very normal and popular cases to set multiple
   IPv6 addresses to one node. One IPv6 node owns more than two IPv6
   addresses (typically: one is link-local scoped address. the other
   is global scoped address) at least. Some IPv6 addresses (such as
   link-local scoped stateless auto-configuration addresses and
   temporary addresses) may become users' conscious-less address,
   because they are automatically set to the IPv6 node.

   It is too difficult for human beings to tell which IPv6 address is
   set to which IPv6 node. In other words, when an IPv6 address is
   shown to a person, he almost can not tell that the shown IPv6
   address indicates which IPv6 node. In this sense, literal IPv6
   address information can be called useless or meaningless
   information for human beings.

H. Kitamura        Expires April 2012                           [Page 2]
Internet Draft     Corresponding Auto Names for IPv6

   So, there are strong desires to use Name information (that is
   gentle for human beings) instead of literal IPv6 Address
   information and to use meaningful information that can easily show
   which IPv6 address / name indicates which actual IPv6 node.

   The Corresponding Auto Names for IPv6 Addresses is introduced to
   solve above problems and to satisfy the above desires.

2. Goals (What can be achieved)

   In this section, goals of the mechanisms of the Corresponding Auto
   Names for IPv6 Addresses and what can be achieved are shown by
   using examples.

2.1 Assumed typical IPv6 communication environment:

   Two IPv6 nodes (Node A and Node B) are located on the same link.
   Their IPv6 Addresses are shown below.

    Node A:        Literal Address
                   ----------------------------------
     MAC Address:  00:0d:5e:b8:80:7b
                   ----------------------------------
     LL-Address:   fe80::20d:5eff:feb8:807b%fxp0
     ULA:          fd01:2345:6789::20d:5eff:feb8:807b
                   fd01:2345:6789::1234
     Global Addr:  2001:DB8::20d:5eff:feb8:807b
                   2001:DB8::1234

    Node B:        Literal Address
                   ----------------------------------
     MAC Address:  00:0c:76:d9:14:e3
                   ----------------------------------
     LL-Address:   fe80::20c:76ff:fed9:14e3%em0
     ULA:          fd01:2345:6789::20c:76ff:fed9:14e3
                   fd01:2345:6789::5678
     Global Addr:  2001:DB8::20c:76ff:fed9:14e3
                   2001:DB8::5678

   They own altogether 5 IPv6 addresses respectively;
     1 Link-Local scoped Address
     2 Unique Local Addresses  (SLLAC address and manual set address)
     2 Global scoped Addresses (SLLAC address and manual set address)
   They communicate each other.

H. Kitamura        Expires April 2012                           [Page 3]
Internet Draft     Corresponding Auto Names for IPv6

2.2 Auto Names examples

   For all addresses, respective Corresponding Auto Names are prepared
   and registered to a name resolving DB and its service (such as the
   DNS) automatically by the mechanism that detects these addresses
   (that is explained after in this document). Prepared Auto Names are
   shown below.

    Node A:        Literal Address                        Auto Name
                   ----------------------------------     ---------
     MAC Address:  00:0d:5e:b8:80:7b
                   ----------------------------------
     LL-Address:   fe80::20d:5eff:feb8:807b%fxp0       -> n7bz-l1%fxp0
     ULA:          fd01:2345:6789::20d:5eff:feb8:807b  -> n7bz-u1
                   fd01:2345:6789::1234                -> n7bz-u2
     Global Addr:  2001:DB8::20d:5eff:feb8:807b        -> n7bz-g1
                   2001:DB8::1234                      -> n7bz-g2

    Node B:        Literal Address                        Auto Name
                   ----------------------------------     ---------
     MAC Address:  00:0c:76:d9:14:e3
                   ----------------------------------
     LL-Address:   fe80::20c:76ff:fed9:14e3%em0        -> n3ez-l1%em0
     ULA:          fd01:2345:6789::20c:76ff:fed9:14e3  -> n3ez-u1
                   fd01:2345:6789::5678                -> n3ez-u2
     Global Addr:  2001:DB8::20c:76ff:fed9:14e3        -> n3ez-g1
                   2001:DB8::5678                      -> n3ez-g2

2.3 Auto Name Prefix for Grouped Addresses

   In order to make Auto Names meaningful, IPv6 addresses are grouped
   and Auto Name Prefix is used to show grouped addresses.

   For IPv6 addresses that are set to the same interface (node), the
   same Auto Name-Prefix that stands for the Group ID is used for
   their Auto Names.

   As shown above:

    'n7bz-' is used for Auto Name Prefix (Group ID) for Node A and
    'n3ez-' is used for Auto Name Prefix (Group ID) for Node B.

   In order to make easier to identify and remember the Auto Name
   Prefixes, their naming rule is based on inheriting the last octet
   of the node's MAC address in this example.

H. Kitamura        Expires April 2012                           [Page 4]
Internet Draft     Corresponding Auto Names for IPv6

2.4  Contribution in Regular Resolving (Name -> Address)

   In order to communicate with the specific IPv6 address of the
   destination node, the following procedure to type literal IPv6
   address is required in the current environment. They are very
   stressful and nuisance procedures for human beings.

   When 'ping6' or 'telnet' to the specific IPv6 address of Node B
   from Node A is executed, the following commands are typed.

    >ping6 fe80::20c:76ff:fed9:14e3%fxp0
    >telnet fd01:2345:6789::20c:76ff:fed9:14e3

   Especially for link-local scoped addresses or temporary addresses,
   there are no way to type Names instead of literal IPv6 addresses,
   because they are generally not registered to name resolving
   services.

   By introducing the Corresponding Auto Names, above typed commands
   are changed and replaced with the following easy and rememberalbe
   name typing procedures.

    >ping6  n3ez-l1%fxp0
    >telnet n3ez-u1

2.5  Contribution in Reverse Resolving (Address -> Name)

   Communication related status information is shown to human beings
   in literal IPv6 address format in the current environment.

    'netstat -a' (on Node A) shows connection status as followed:

 Local Address                 Foreign Address               (state)
 fe80::20d:5eff:feb8:807b.8722 fe80:3::20c:76ff:fed9:14e3.23 ESTABLISH
 fd01:2345:6789::1234.16258    fd01:2345:6789::5678.23       TIME_WAIT

H. Kitamura        Expires April 2012                           [Page 5]
Internet Draft     Corresponding Auto Names for IPv6

    'ndp -a' (on Node A) shows neighbor cache status as followed:

 Neighbor                            Linklayer Addr.  Netif Expire   S
 fe80::20d:5eff:feb8:807b%fxp0       0:0d:5e:b8:80:7b fxp0 permanent R
 fd01:2345:6789::20d:5eff:feb8:807b  0:0d:5e:b8:80:7b fxp0 permanent R
 fd01:2345:6789::1234                0:0d:5e:b8:80:7b fxp0 permanent R
 2001:DB8::20d:5eff:feb8:807b        0:0d:5e:b8:80:7b fxp0 permanent R
 2001:DB8::1234                      0:0d:5e:b8:80:7b fxp0 permanent R
 fe80::221:85ff:fea7:82ff%fxp0       0:21:85:a7:82:ff fxp0 23h50m51s S
 fe80::20c:76ff:fed9:14e3%fxp0       0:0c:76:d9:14:e3 fxp0 23h51m56s S
 fd01:2345:6789::20c:76ff:fed9:14e3  0:0c:76:d9:14:e3 fxp0 23h52m50s S
 fd01:2345:6789::5678                0:0c:76:d9:14:e3 fxp0 23h53m51s S
 2001:DB8::20c:76ff:fed9:14e3        0:0c:76:d9:14:e3 fxp0 23h54m53s S
 2001:DB8::5678                      0:0c:76:d9:14:e3 fxp0 23h55m54s S

   People almost can not tell which shown literal IPv6 address
   indicates which IPv6 node. In this sense, shown information is
   meaningless and useless.

   By introducing the Corresponding Auto Names, above complicated
   information is converted into simple and meaningful information and
   shown as followed.

    'netstat -a' (on Node A) shows connection status as followed:

 Local Address                 Foreign Address               (state)
 n7bz-l1.8722                  ne3z-l1.23                    ESTABLISH
 n7bz-u1.16258                 ne3z-u1..23                   TIME_WAIT

    'ndp -a' (on Node A) shows neighbor cache status as followed:

 Neighbor                            Linklayer Addr.  Netif Expire   S
 n7bz-l1%fxp0                        0:0d:5e:b8:80:7b fxp0 permanent R
 n7bz-u1                             0:0d:5e:b8:80:7b fxp0 permanent R
 n7bz-u2                             0:0d:5e:b8:80:7b fxp0 permanent R
 n7bz-g1                             0:0d:5e:b8:80:7b fxp0 permanent R
 n7bz-g2                             0:0d:5e:b8:80:7b fxp0 permanent R
 nffz-l1%fxp0                        0:21:85:a7:82:ff fxp0 23h50m51s S
 n3ez-l1%fxp0                        0:0c:76:d9:14:e3 fxp0 23h51m56s S
 n3ez-l1                             0:0c:76:d9:14:e3 fxp0 23h52m50s S
 n3ez-l2                             0:0c:76:d9:14:e3 fxp0 23h53m51s S
 n3ez-g1                             0:0c:76:d9:14:e3 fxp0 23h54m53s S
 n3ez-g2                             0:0c:76:d9:14:e3 fxp0 23h55m54s S

H. Kitamura        Expires April 2012                           [Page 6]
Internet Draft     Corresponding Auto Names for IPv6

   Other examples where the Auto Name technique can contributes:

   In log files of a server application, accesses from clients are
   recoded into them in literal IPv6 address format. It is almost
   impossible to read and understand the log files effectively without
   this Auto Name technique.

   Also, in packet dumping applications, address information is shown
   in literal IPv6 address format. This Auto Name technique can
   significantly help for human beings to analyze and understand
   dumped packets.

   Shown communication related status information in Auto Name format
   is simple and easy enough for human beings to understand. As shown
   above, troublesome IPv6 literal Address information can be
   converted into meaningful information by using the Corresponding
   Auto Names technique, and we can achieve our goals.

3 Deployed Notions and Functions that are used in Auto Names

3.1. Stateless Name

   We know that we can categorize Addresses into two types. One is
   "stateful" address type, and the other is 'stateless' address type.

   On the other, we have not been applied the same categorization to
   domain Names or host Names clearly. It has been assumed that
   existing all Names are categorized into stateful type and there is
   no stateless name type. Authors think that it is a time to change
   this preconception.

   We can grasp that the introduced Corresponding Auto Name is
   realization of "stateless" name type, and we have deployed a notion
   Stateless Name clearly here.

3.2  Scoped Name

   We also know that a notion called "scope" (such as link-local
   scope, global-scope) is introduced when we deal with addresses.
   Every address has its own scope.

   In domain Names or host Names cases, the "scope" notion have not
   clearly introduced.  It is assumed that all names are global
   information and "scope" notion does not exist.

   The Corresponding Auto Name is achieved by introducing Scoped Name
   obviously.

H. Kitamura        Expires April 2012                           [Page 7]
Internet Draft     Corresponding Auto Names for IPv6

   Scope of Auto Name for IPv6 address is the same to the scope of its
   IPv6 address. For example, scope of the Auto Name for the link-
   local IPv6 address is link-local. They are only effective within
   the link-local scope.

3.3 Target IPv6 Addresses

   One of the goals of the Auto Name technique is to provide and set
   Names to all IPv6 addresses.

   If an address has its own name and it is registered into name
   resolving services (such as the DNS) already, it is basically not
   necessary to provide Auto Name to such addresses.

   We can assume that IPv6 addresses whose names are registered into
   the name resolving services are well managed. So, they will not
   become targets of the Auto Name technique. However, we can provide
   Auto Names to such addresses, because one-to-multiple mapping is
   allowed in name resolving services.

4. Design of Auto Names

4.1 Conceptual Design on Naming Rules

    Auto Names are composed of "<NGI>-<P><I>" format:

    <NGI>: stands for Node (Interface) Group ID

        4 characters (starting from 'n')
          (e.g., 'n7bz', 'n3ez')

    <P>: stands for Prefix of Address

        1 character: (e.g., 'l', 'u', 'g')

    <I>: stands for Interface ID of Address

        1 character: (e.g., '1', '2')

    Above discussed Auto Name examples satisfy <NGI>-<P><I> format.

      on Node A: n7bz-l1, n7bz-u1, n7bz-u2, n7bz-g1, n7bz-g2
      on Node B: n3ez-l1, n3ez-u1, n3ez-u2, n3ez-g1, n3ez-g2

H. Kitamura        Expires April 2012                           [Page 8]
Internet Draft     Corresponding Auto Names for IPv6

4.1.1 <NGI> Value:

   <NGI> value is also called Auto Name-Prefix.

   In order to make IPv6 addresses meaningful, IPv6 addresses are
   grouped. It is very natural to group IPv6 addresses by which node
   (interface) they are set. So, IPv6 addresses that are set to the
   same node (interface) are grouped into the same group.

   <NGI> value is shown as 'nXYZ' format:
    'n' : (1st char) fixed and not changed
    'XY': (2nd, 3rd chars) are inherited from
           the last octet (2 charters) of the node's MAC address
    'Z' : (4th char) suffix char to avoid a collision of 'XY'
           starting from "z"
           if 'XY' is collided, 'Z' is changed into "y", "x" ,,,

   By using the birthday paradox theorem, collision probability of 256
   states (1 octet) is calculated. If there are 19 nodes (interfaces),
   collision is happened with 50% probability.

   Collision check procedure of the last octet of MAC addresses is
   necessary.

4.1.2 <P> Value:

   <P> value stands for Prefix (Scope) of Address as 1 character
   format.

   Auto Names of IPv6 addresses whose prefixes are same use the same
   <P> value.

   Typically, following characters are used:
    "l":  used for link-local scoped addresses.
    "u":  used for ULA
    "g":  used for global scoped address

   If multiple prefixes for the same scope are used, other character
   (such as "h", "i",,,) can be used depending on the circumstances.

4.1.3 <I> Value:

   <I> value stands for Interface ID of Address as 1 character format.

   <I> value is starting from "1". If multiple IPv6 addresses whose
   <NGI> and <P> values are same are found, other <I> value (such as
   "2", "3",,,) is used.

H. Kitamura        Expires April 2012                           [Page 9]
Internet Draft     Corresponding Auto Names for IPv6

4.2 IPv6 Address Appearance Detection and Auto Name Registration

   In order to generate and register Auto Names automatically, two
   types of mechanisms are needed. One is a mechanism that detects
   IPv6 address appearance. The other is a mechanism that checks the
   detected addresses and generates Auto Names and registers them to
   name service.

   Two functions ("Detector" and "Registrar") are introduced.
   Detector" function takes in charge of the former mechanism, and
   "Registrar" takes in charge the latter mechanism.

4.2.1 IPv6 Address Appearance Detection mechanism

   In order to detect newly appeared IPv6 address, DAD message (NS for
   DAD) is effectively used.

   DAD message has the following good capabilities:

   - issued only when node would like to set new IPv6 address

   - issued for All types (link-local, global, temporary,,,)

   - L2 broadcast and easy to capture (without using mirror port)

   - distinguishable from other NS messages, because source address of
     the message is unspecified ("::") and different from others

   - Captured DAD message includes all necessary information (such as,
     IPv6 address and MAC address)

   Detector captures DAD messages and detects newly appeared IPv6
   addresses. Detected information is sent to Registrar.

4.2.2 Auto Names Generation and Registration mechanism

   At first, Registrar checks the Detected address information that is
   sent from Detector(s). By using the reverse resolving (Address ->
   Name), it is checked whether the Detected address information is
   first appearance or not.  If an entry for the address does NOT exist,
   it is confirmed that the address is first appearance and it should be
   registered to the name server.

   After Name for the address is prepared, duplication of the Name can
   be checked by using the regular resolving (Name -> Address). If an
   entry for the Name exist, it is confirmed that Name is duplicated
   (collided). Another Name is prepared and checked again until the Name
   is not duplicated.

H. Kitamura        Expires April 2012                          [Page 10]
Internet Draft     Corresponding Auto Names for IPv6

   Finally, Registrar registers both Regular and Reverse resolving
   entries for the address and prepared Auto Name are registered to the
   name server.

4.2.3 Placement of Detector and Registrar

   Placement of Detector and  Registrar is designed to make the mecha-
   nisms flexible and to make it to be applied to various environments
   (office networks, home networks, etc.)

   Figure 1 and 2 show typical examples that indicate locations where
   Detector and Registrar functions are placed on the IPv6 network.
   Figure 1 shows a case for a single link, and Figure 2 shows a case
   for multiple links.

               |                                 +------------+
               |                                 | Name Server|
             +-+-+  %%%%%%%%%%%%  #############  +------+-----+
             | R |  % Detector %  # Registrar #        /
             +-+-+  %%%%%%%%%%%%  #############       +---+
               |         |              |                /
           ----+---------+-------+------+---------------+-----
                                 |
                           +===========+
                           | IPv6 Node |
                           +===========+

                      Fig. 1 Single-Link Case Example

                                         +------------+
                                         | Name Server|
                     #############       +------+-----+
                     # Registrar #             /
                     #############            +---+
                           |                     /
           ----+-----------+------------+-------+------
               |                        |
             +-+-+   %%%%%%%%%%%%%    +-+-+   %%%%%%%%%%%%%
             | R1|   % Detector1 %    | R2|   % Detector2 %
             +-+-+   %%%%%%%%%%%%%    +-+-+   %%%%%%%%%%%%%
               |           |            |           |
           ----+-----+-----+-----   ----+-----+-----+-----
                     |                        |
               +===========+            +===========+
               | IPv6 Node |            | IPv6 Node |
               +===========+            +===========+

                     Fig. 2 Multiple-Link Case Example

H. Kitamura        Expires April 2012                          [Page 11]
Internet Draft     Corresponding Auto Names for IPv6

4.2.4 Detection and Registration Procedures

   Figure 3 shows an example of typical detection and registration pro-
   cedures at IPv6 links where DAD packets are issued. DAD message pack-
   ets are used for the appearance detection.

   IPv6 Node    Router     Detector     Registrar    Name Server

     | link local |          |          |            |
  (a)|---DAD NS--->--------->|          |            |
  (b)|    no NA   |          |(detect)  |            |
  (c)|            |          |=========>|            |
  (d)|            |          |          |----------->|(Reverse Check)
  (e)|            |          |          |<-----------|
     |            |          |          |            |
  (f)|            |          |          |----------->|(Regular Check)
  (g)|            |          |          |<-----------|
     |            |          |          |            |
  (h)|            |          |          |===========>|(Reg. Register)
  (i)|            |          |          |<-----------|
  (j)|            |          |          |===========>|(Rev. Register)
  (k)|            |          |          |<-----------|
     |   global   |          |          |            |
  (l)|(----RS--->)|          |          |            |
  (m)|<----RA-----|          |          |            |
  (n)|---DAD NS--->--------->|          |            |
  (o)|    no NA   |          |(detect)  |            |
  (p)|            |          |=========>|            |
     |            |          |          |            |
  (q)|            |          |          |----------->|(Reverse Check)
  (r)|            |          |          |<-----------|
     |            |          |          |            |
  (s)|            |          |          |----------->|(Regular Check)
  (t)|            |          |          |<-----------|
     |            |          |          |            |
  (u)|            |          |          |===========>|(Reg. Register)
  (v)|            |          |          |<-----------|
  (w)|            |          |          |===========>|(Rev. Register)
  (x)|            |          |          |<-----------|
     |            |          |          |            |

H. Kitamura        Expires April 2012                          [Page 12]
Internet Draft     Corresponding Auto Names for IPv6

5. Security Considerations

   Auto Names are generated and registered to the name service in this
   document. In order to register correct Auto Names information, commu-
   nication between Detector and Registrar and communication between
   Registrar and Name Server should be protected and be secured.

   In general usage, scope of Auto Names will be local (not global).
   Auto Names are usually local scoped names. So, we do not have to be
   too sensitive on the correctness of Auto Names.

6. IANA Considerations

   This document does not require any resource assignments to IANA.

References

  Normative References

   [RFC4291] R. Hinden and S. Deering, "IP Version 6 Addressing Archi-
              tecture", RFC 4291, February 2006

   [RFC4861] T. Narten, E. Nordmark, W. Simpson and H. Soliman, "Neigh-
              bor Discovery for IP Version 6 (IPv6)," RFC 4861, Septem-
              ber 2007

   [RFC4862] S. Thomson, T. Narten and T. Jinmei "IPv6 Stateless Address
               Autoconfiguration," RFC4862, September 2007

   [RFC4941] T. Narten, R. Draves and S. Krishnan, "Privacy Extensions
              for Stateless Address Autoconfiguration in IPv6," RFC4941,
              September 2007

   [RFC1034] P. Mockapetris, "Domain names - concepts and facilities ",
              RFC 1034, November 1987

   [RFC1035] P. Mockapetris, "Domain names - implementation and specifi-
              cation", RFC 1035, November 1987

   [RFC2136] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, "Dynamic
              Updates in the Domain Name System," RFC 2136, April 1997

   [RFC4795] B. Aboba, D. Thaler, and L. Esibov, "Link-Local Multicast
              Name Resolution (LLMNR)," RFC4795, January 2007

  Informative References

H. Kitamura        Expires April 2012                          [Page 13]
Internet Draft     Corresponding Auto Names for IPv6

   [RFC4620] M. Crawford and B. Haberman, "IPv6 Node Information
              Queries," RFC4620, August 2006

   [mDNS] S. Cheshire and M. Krochmal, "Multicast DNS" <draft-cheshire-
              dnsext-multicastdns-14.txt> work in progress, February
              2011

   [RFC3849] G. Huston, A. Lord and P. Smith, "IPv6 Address Prefix
              Reserved for Documentation," RFC3849, July 2004

Authors' Addresses

   Hiroshi Kitamura
   Service Platform Research Laboratories, NEC Corporation
   (SC building 12F)1753, Shimonumabe, Nakahara-Ku, Kawasaki,
   Kanagawa 211-8666, JAPAN
   Graduate School of Information Systems,
   University of Electro-Communications
   5-1 Chofugaoka 1-Chome, Chofu-shi, Tokyo 182-8585, 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

H. Kitamura        Expires April 2012                          [Page 14]