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 -------------------- On Mon, 2006-10-09 at 15:35 -0700, Tony Hain wrote: > 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 PROTECTED] > > Sent: Friday, September 29, 2006 8:13 AM > > To: ipv6@ietf.org > > 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
