Internet-Draft                                                        Pars Mutaf
Expires: 26 April, 2007                 Institut National des Telecommunications
                                                                    Evry, France
                                                                26 October, 2006

          Human-regenerable IPv6 interface identifiers and addresses

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on 26 April, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses
   and restrictions contained in BCP 78, and except as set forth
   therein, the authors retain all their rights.


   This document defines the human-regenerable IPv6 interface identifiers
   and addresses.

Mutaf                      Expires 26 April, 2007                       [Page 1]

Internet-Draft   Human-regenerable IPv6 interface identifiers    26 October 2006

1. Introduction

   This document defines the human-regenerable IPv6 interface identifiers and
   addresses. They are constructed from easily remembered or guessed character
   strings input by the user. Human-regenerable addresses can bring convenience
   in some ad-hoc scenarios, i.e. when a centralized DNS service is not

   This document does not specify the type of character strings that can be
   used in human-regenerable IPv6 addresses. Human names, pseudonyms, other
   simple strings with different meanings, or short phrases may be used
   depending on user imagination and needs.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2. Human-regenerable IPv6 addresses

   This document refers to the type of IPv6 addresses where the leftmost 64 bits
   of a 128-bit address form the subnet prefix and the rightmost 64 bits of the
   address form the interface identifier [IP6ARCH].  Human-regenerable addresses
   are based on a construct called HUMID (HUMan-regenerable interface ID).
   HUMIDs are constructed by computing a cryptographic hash of an easily
   remembered or guessed character string, such as a "human name". For example,
   a hand-held personal device e.g. cellular phone or personal digital
   assistant can be given the HUMID constructed from its user's first and last
   names. In some cases, pseudonyms or other simple strings may also be used,
   depending on user imagination and needs.

   On the same link, a host can easily contact another host at its HUMID (modulo
   human typing erroneous name). The link-local prefix is constant, well-known
   and specified in [IP6ARCH]. A hosts on the same link can be reachable at its
   IPv6 address constructed as follows:

        10 bits           54 bits                    64 bits
      |1111111010|           0             |           HUMID            |
      <--------link-local IPv6 prefix-----><-------interface ID -------->
               (completed by the host)           (human-generated)

   The HUMID interface identifier is constructed using the string input by the
   user, and the prefix is completed by host. The HUMID can be based on the
   user's first and last name, for example. The resultant address is
   human-regenerable. Any user who knows the name, can regenerate the same IPv6
   address and reach the host. Similarly, the link-local prefix will be
   completed by the host.

   If well-known, other subnet prefixes than the link-local IPv6 prefix MAY
   be used.

Mutaf                      Expires 26 April, 2007                       [Page 2]

Internet-Draft   Human-regenerable IPv6 interface identifiers    26 October 2006

   The following steps are required for address configuration:

  - The user input character string, possibly pre-formatted as described in
    Appendix A, MUST be input to the SHA-1 [SHA] hash function. The HUMID
    interface identifier is obtained by taking the leftmost 64 bits of the
    160-bit SHA-1 hash value, and setting bit 6 (the left-most bit is numbered
    0) to zero. This creates a HUMID with the universal/local bit indicating
    local significance only.

  - The 64-bit subnet prefix and the 64-bit HUMID are concatenated to form a
    128-bit IPv6 address with the subnet prefix on the left and interface
    identifier on the right, as specified in [IP6ARCH].

   The resultant IPv6 address MUST be tested for local uniqueness using the
   Duplicate Address Detection (DAD) mechanism specified in [SAA]. Upon
   detecting a duplicate address, the user MUST be notified. The user MUST try
   another character string.

3. Usage example: Ad-hoc Network

   In the following discussion, a wireless ad-hoc networking scenario is
   described and the address/name configuration complexity is analyzed. It is
   shown that human-regenerable IPv6 addresses bring convenience.

          Alice, Franck, Mary, David, Eric, Carol

   Each user has a personal portable device equipped with ad-hoc mode wireless
   interface e.g. 802.11. Each user may need communicate with any other user,
   and hence IPv6 addresses and/or names have to be configured and distributed
   in a convenient way.

        Solution #1:

               Alice  configures a simple IPv6 address fe80::1
               Franck configures a simple IPv6 address fe80::2
               Mary   configures a simple IPv6 address fe80::3
               David  configures a simple IPv6 address fe80::4
               Eric   configures a simple IPv6 address fe80::5
               Carol  configures a simple IPv6 address fe80::6

   This approach is not practical. The users need to communicate (orally, for
   example) with each other during address configuration. Otherwise address
   collisions are very probable. It is unclear who should configure which
   address. It is also difficult to remember who configured which address.

        Solution #2:

         Alice  configures a unique address fe80::212 :3fff:fe79:f820
         Franck configures a unique address fe80::86f7:e437:faa5:a7fc
         Mary   configures a unique address fe80::e9d7:1f5e:e7c9:2d6d
         David  configures a unique address fe80::84a5:1684:1ba7:7a5b
         Eric   configures a unique address fe80::3c36:3836:cf4e:1666
         Carol  configures a unique address fe80::58e6:b3a4:14a1:e090

Mutaf                      Expires 26 April, 2007                       [Page 3]

Internet-Draft   Human-regenerable IPv6 interface identifiers    26 October 2006

   This approach has two problems. Firstly, the addresses are hard to remember
   and hard to pronounce. Each address can be given a simple name and stored
   in each device (for example, in the /etc/hosts file in Unix systems).
   However, it is unclear how the addresses can be distributed. Secondly, this
   method is vulnerable to loss of state. It is very hard (if not impossible) to
   recover from loss of state.

        Solution #3:

   Each user configures an address from his/her human name. Assuming that the
   users know each other, they can easily regenerate each other's address at
   any time in a stateless manner. (See Appendix B for practical details on
   using human-regenerable addresses).

   This document defines and recommends Solution #3.

4. Security considerations

   Human-regenerable addresses are not different from a regular IPv6 address.
   They can be impersonated. For example, sending a short message to a
   destination user's human-regenerated address is not secure. There is no
   guarantee that the message will be received by the intended destination.
   Human-regenerable address ownership of a responder can be verified during a
   voice session, since the initiator will recognize the responder's voice. The
   secure use of human-regenerable addresses is therefore better ensured with
   interactive voice communication.

5. Conclusion

   This document described the human-regenerable IPv6 interface identifiers and
   addresses. In some ad-hoc scenarios, human-regenerable IPv6 addresses can
   bring convenience.

   Human-regenerable IPv6 addresses may have other applications that are not
   described in this document. For example, interface identifiers constructed
   from human name may be used as a replacement for the stateful "phone book"
   in cellular hosts. Currently cellular device identifiers are not publicly
   available, for privacy reasons probably. There is also anectodical evidence
   that users often loose the list of their correspondent nodes (accidentally
   upon loss of state, or when their device is lost/stolen/changed). A special
   protocol may be built ontop of human-regenerable IPv6 addresses, in order to
   overcome these difficulties: initiator can generate a request to the host
   "John Smith", and John Smith's host can return its phone number (if accepted
   by John Smith). The design of this protocol (for example, handling of name
   collisions) falls beyond the scope of this document.

Mutaf                      Expires 26 April, 2007                       [Page 4]

Internet-Draft   Human-regenerable IPv6 interface identifiers    26 October 2006


[IP6ARCH]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
           Addressing Architecture", RFC 3513, April 2003.

[SAA]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address
       Autoconfiguration", draft-ietf-ipv6-rfc2462bis-08 (work in progress),
       May 2005.

[SHA]  National Institute of Standards and Technology, "Secure Hash Standard",
       Federal Information Processing Standards Publication FIPS PUB 180-1,
       April 1995, <>.

       November 1987.

Author's Address

   Pars Mutaf
   Institut National des Telecommunications

   This document and the information contained herein
   are provided on an "AS IS" basis and THE CONTRIBUTOR, THE

Appendix A. Character string disambiguation

   A same character string may be entered in different ways (by different users,
   or by the same user at different times). For example, the following string
   may be entered as:

      Jean-Francois Le Roux
      Jean Francois Le Roux
      jean-francois le roux
      jean francois le roux
      Jean-Francois Leroux
      Jean Francois Leroux
      jean-francois leroux
      jean francois leroux

   A user cannot be reproached for entering the same character string
   differently. More than one string representations may be considered correct,
   especially in the computer world. One user may use a particular upper case
   character, but another user may not. A user may use a white space between two
   words, but another user may use a point or dash, etc. When input to a
   cryptographic hash function (as described above), these nuances will yield
   different outputs and foil the interoperability of human-regenerable
   identifiers addresses.

Mutaf                      Expires 26 April, 2007                       [Page 5]

Internet-Draft   Human-regenerable IPv6 interface identifiers    26 October 2006

   This document therefore recommends the following techniques:

   Special characters that lead to doubtful concatenation (white space, dash,
   point, etc.) SHOULD be removed. A character SHOULD be removed by being
   replaced by the character on the right (if any). All upper case letters
   SHOULD be converted to their lower case counterpart. When these rules are
   applied to the above given examples, they all become:


   regardless of how they are entered by the user. This facilitates the
   successful matching of a HUMID generated by different users. String ending
   characters (such as '\0' in C language) may also lead to doubt. They
   SHOULD NOT be input to the hash function.

Appendix B. Applying human-regenerable addresses

   This section presents a possible technique for applying human-regenerable
   IPv6 addresses. Other techniques, using a graphical user interface for
   example, may also be applied. In this section, it is assumed that a command
   called "humid" is available. The command takes a character string and outputs
   a link-local IPv6 address as follows (Unix jargon):

        commandline> humid "hello world"

   An IPv6 address can be configured as follows (assuming that network the
   network interface is "eth0"):

        commandline> ifconfig eth0 inet6 add `humid "hello world"`

   The host "hello world" can be pinged as follows:

        commandline> ping6 -I eth0 `humid "hello world"`

   The host "hello world" can be reached through ssh, as follows:

        commandline> ssh `humid "hello world"`%eth0

   Alternatively, the humid command can be used for bootstrapping the /etc/hosts
   file and using standard name resolution routines. For example the following

        commandline> echo "alpha `humid alpha`" >> /etc/hosts

   will add the entry

        alpha fe80::be76:331b:95df:c399

   to the /etc/hosts file. At this point the host "alpha" can be reached using
   standard name resolution routines.

Mutaf                      Expires 26 April, 2007                       [Page 6]