Dear IPv6 WG, I'm wondering if we need an RFC to make the following application available and usable:
(The draft is here please: http://www.ietf.org/internet-drafts/draft-mutaf-ipv6humid-01.txt ) Imagine a command called "humid" (If you don't want to imagine it, I can send you the code). It takes a character string and it outputs a link-local scope IPv6 address as follows: [EMAIL PROTECTED] humid "hello world" fe80:0000:0000:0000:573a:ffc8:6648:540e [EMAIL PROTECTED]:~$ You don't need to modify existing commands. If you wish to configure an IPv6 address from "hello world", you need to type the following command: [EMAIL PROTECTED] ifconfig eth0 inet6 `humid "hello world"`/64 [EMAIL PROTECTED]:~$ If you wish to ping, telnet, scp, etc, the host "hello world", you would type: [EMAIL PROTECTED] ping6 -I eth0 `humid "hello world"` [EMAIL PROTECTED]:~$ This looks feasible for someone with system skills. I think you prefer this to typing an address like fe80::212:3fff:fe79:f820. You can't remember such an address. But you can remember a meaningful character string. With a GUI, it can be made even more user friendly. This is an easy/quick replacement for DNS. You can use it when you are to stressed to install/configure a DNS. ;-) Or, you can you it until you have DNS. I wish I had this standard command right away when I install an IPv6 machine. Note also that it can work without L2 multicast support. The duplicate address detection discussion in the I-D should go? (issue raised by Tony Hain). With this kind of usage, DAD is useless UIMS. The duplicate address is configured anyway by ifconfig (in Linux). So the user must find unique names. This applies to all kind of IPv6 addresses. My argument is that RFC is desirable and worth your time, for 2 reasons: 1. Choice of the hash function in different systems (the I-D specifies SHA-1) 2. Some character string pre-formatting is desirable as described in the I-D. For example, white spaces should be removed etc. I'm also OK for removing all references to remote use of HUMIDs. Global-scope humid addresses will be proposed in another context (please see below, if you are interested). Thanks, pars =================== Second note: For interested people, there is also the following possibility which is a much more ambitious project using HUMIDs. Although this goes far beyond this WG's scope, if you have suggestions (e.g. where to present it) please let me know. Topic: A peer-to-peer protocol that replaces the "phone book" This is actually a new motivation of human-regenerable IPv6 addresses that I'm presenting you here. I'm not assuming that DNS or MIPv6 home agent is down. They work like a charm. Routers also are running smoothly... In order reach a correspondent node, his/her high-level identifier, e.g. a phone number, is needed. This assumes that all users are subscribed to a public phone book (and this service is always reachable), or the correspondent node's identifier is registered in the initiator device's memory. These assumptions do not always hold. Currently cellular device identifiers are not publicly available. There is also anecdotal evidence that users often loose the list of their correspondent nodes (accidentally upon loss of state, or when their device is lost/stolen/changed). On top of HUMID addresses, one can build the following p2p program that replaces the stateful phonebook in the personal phones: The same program is assumed to be running on many nodes (that need this service). Each personal device configure an HUMID IPv6 address from its user's human name and listen on it at a well-known port number. One can contact the user "John Smith" by sending a request to his address constructed from "John Smith". His phone will return its phone number (and possibly other info), and initiator application will launch a VoIP application and call him. The initator will cache the phone number. The program is also capable of learning the IPv6 subnet prefixes. Consequently, a human name can be searched in multiple subnets. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
