Subject: RE: [Fwd: Re: humid IPv6 addresses]

From: "Tony Hain" <[email-masked]>
Date: Mon, 9 Oct 2006 15:35:09 -0700

I am not sure the collision approach is practical, and even if it is the
description needs more detail. This approach assumes that an implementation
will know that the wrong node has been reached when there are multiple
systems that are trying to create the same string, then back off and try
again on the incremented IID. I am not aware of any system that will retry
256 times before giving up, and even if they did it is not clear how they
know they reached the wrong node. As long as the dst port is open the only
way would be a higher layer crypto check, or a user recognized error.
Neither will cause the stack to retry.

The entire discussion about making this work over distance needs to be
removed. The collision section should be simplified to just have the user
change the hash input string when there is a collision. This is practical
when the use case is local ad-hoc. The logic for having part of the address
be typed in as hex and part as a string is just broken, so all references to
remote use need to go. 

Tony

> -----Original Message-----
> From: Pars Mutaf [mailto:[email-masked]]
> Sent: Friday, September 29, 2006 8:13 AM
> To: [email-masked]
> Subject: [Fwd: Re: humid IPv6 addresses]
> 
> Dear IPv6,
> 
> FYI, I have received the following comments on
> the human-regenerable IPv6 interface IDs and
> addresses (from the DNSEXT WG).
> 
> I've also been told that humid addresses may
> be helpful when L2 multicast isn't supported,
> in Wimax for example
> (other mechanisms e.g. IPv6 Node Information
> Queries need L2 multicast for name resolution
> UIMS).
> 
> With humid, there is also the possibility of
> searching a mobile host in multiple subnets.
> 
> Regards,
> pars
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 10 Oct 2006 18:29:38 +0200

Hi and thank you for your comments. You have two issues:

1/ how to detect that wrong node has been reached
2/ the logic of remote use is broken

In this mail I'm responding to the 1st one. I take note of 
2nd one but I'll reply later in a separate mail. I'm not 
against removing all references to remote use of HUMIDs, 
but I'd would like to try once more before giving up ;-)

In this mail: 

Below, please find the new text on 
how to detect that wrong node has been reached. 
For the old parts of the I-D, click:
http://www.ietf.org/internet-drafts/draft-mutaf-ipv6humid-01.txt

pars

------------------- 8<   cut here   --------------------

4. Reaching a host at its human-regenerable address

When attempting to contact a host at its human-regenerated
address, the initiator SHOULD first try a target address with
a collision count set to 0. Upon each failure (if any), the
collision count SHOULD be incremented by 1, before retrying.

A "failure" is defined as the case where a host with the 
same NAME is reached or detected but it is not the intended
destination. I.e., the source has chosen a collision count 'i',
the intended destination's address was configured with a 
collision count 'j'. However, the collision counts 'i' and 'j'
do not match.

This document describes two possible approaches to failure 
detection (or, searching the intended destination). 

4.1 One by one

This mode of operation is suitable for interactive
voice/video applications, where users can recognize each other.
This protocol is currently being used when for example multiple
occurrences of the same human name are found in a phone book 
(e.g. white pages). The session initiating user needs to call
different numbers until the intended destination is reached.

The same user-level protocol can be used with human-regenerable
addresses. Upon failure, the session initiating 
user can close the session and tell the application to try the 
next address. As described above, the application will increment 
the collision count and call the next address.

The choice of the number of attempts are left to the user.

It can also be noted that there is a non-negligible chance 
factor with human name collisions. Some "favored" users have a
human name that is likely to be very rare (if not globally
unique), while others have very common names. This issue is
orthogonal to this document.

4.2 All at once

Some applications may adopt the following protocol to find 
out the intended destination:

The session initiating application can generate a query packet
to the first 'n' addresses constructed with collision counts
0,1,2, ..., n. Upon receipt of the query, each contacted 
host can return detailed information on the host and/or 
user, e.g. a certificate. With this protocol, the initiator 
will receive m (where, m <= n) different replies prior to 
communication. The user or application will select one of 
the destinations and the session will be established.

The specification of the protocol to achieve this mode 
(i.e., query/reply packets and port number if any) is out 
of this document's scope.

------------------- 8<    cut here --------------------

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 17 Oct 2006 14:51:09 +0200

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:

pars@lazylizard$ humid "hello world"
fe80:0000:0000:0000:573a:ffc8:6648:540e
pars@lazylizard:~$

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:

pars@lazylizard$ ifconfig eth0 inet6 `humid "hello world"`/64
pars@lazylizard:~$

If you wish to ping, telnet, scp, etc, the host "hello world",
you would type:

pars@lazylizard$ ping6 -I eth0 `humid "hello world"`
pars@lazylizard:~$

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.

---

From: Pars Mutaf <[email-masked]>
Date: Thu, 26 Oct 2006 18:16:17 +0200

Hi folks (sorry for popping up), 

FYI, based on comments I have very much simplified 
the humid draft. You can find it here until it 
appears in the I-D rep.:

http://www.freewebs.com/pmutaf/draft-mutaf-ipv6humid-02.txt

Usage scenario is ad-hoc network now. 
All references to infrastructure DNS, MIP6 etc. 
are gone.
I also explain how to use HUMIDs under
standard name resolution routines.

A stateless phonebook possibility is briefly
mentioned in the conclusion but left to 
future work.

Acknowledgments are also left to future work :-/

Regards,
pars

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 31 Oct 2006 17:52:16 +0100

Code (simple, just to show the principle, and README):
http://www.freewebs.com/pmutaf/humid_code.tgz

Motivations:

Thanks,
pars
(ps: sensor folks are also interested.)