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- 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 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. Abstract 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 available. 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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. Users: 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 References [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, . [DNS] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1035, November 1987. Author's Address Pars Mutaf Institut National des Telecommunications Email: pars.mutaf@int-evry.fr This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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: jeanfrancoisleroux 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" fe80::6adf:b183:a4a2:c94a commandline> An IPv6 address can be configured as follows (assuming that network the network interface is "eth0"): commandline> ifconfig eth0 inet6 add `humid "hello world"` commandline> 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 command: 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]