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 --------------------------------------------------------------------
