RE: [Fwd: Re: humid IPv6 addresses]
Pars Mutaf <pars.mutaf <at> int-evry.fr>
2006-10-10 16:29:38 GMT
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:pars.mutaf <at> int-evry.fr]
> > Sent: Friday, September 29, 2006 8:13 AM
> > To: ipv6 <at> 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 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
RSS Feed