On Wed, 2006-07-12 at 09:16 -0400, Brian Haberman wrote: > Hi Pars, > One issue I see with this is string internationalization. > Defining the format of a name is not trivial given the current work to > internationalize names, strings, etc. to support languages that do not > use a Latin-based alphabet. For example, how would one format a name > in a double-byte language is well outside the scope of the IPv6 WG. >
Hi, Thanks. I was expecting this kind of remark. I'll try to make reference to an existing standard language, in a future version of the draft (if technically possible). I will also specify which hash function to use etc. Thanks! Regards, pars > Regards, > Brian > > On Jul 11, 2006, at 5:17, Pars Mutaf wrote: > > > On Mon, 2006-07-10 at 17:04 -0700, Peter Sherbin wrote: > >> Pars, > >> > >> Why would you need IETF to tell you which human name format to use. > >> Technically any > >> and all bits to the right of the network boundary are yours and you > >> can do with them > >> whatever you want. > > > > Hi, > > > > That's right, we can do whatever we want. However: > > > > If my host configures an interface ID from 64bithash(pars mutaf), > > but someone tries to reach me at 64bithash(parsmutaf), > > this won't work.. A standard human name format is needed. > > > > (is this off-topic?) > > > > pars > > > > > >> > >> Thanks, > >> > >> Peter > >> > >> --- Pars MUTAF <[EMAIL PROTECTED]> wrote: > >> > >>> > >>> Hello, > >>> > >>> For example, we are in the same campus. The campus is covered > >>> by a single subnet with several wireless access points. I need > >>> to call you. But there is a problem and I can't get the IPv6 address > >>> of your cellular phone (DNS, or MIPv6 home agent failure). > >>> > >>> But, I suspect > >>> that you are probably in the campus (because you work here). > >>> Since we are in the same campus (and, in this example, in the same > >>> subnet), we are receiving the same router advertisements. > >>> Consequently, > >>> I know your subnet prefix. I also know your name, then > >>> I can construct your HUMID (interface ID based on HUMan name). > >>> It is: 64bithash(Bob Hinden). Then, I can reach you (if you're really > >>> in the campus). > >>> > >>> Now, imagine a different campus. This campus is covered by 5 > >>> subnets. I work in this > >>> campus. In the past I visited different > >>> parts of the campus, and my phone recorded all of the subnet prefixes > >>> that it received from the routers (in the recent past). My phone > >>> has now the list of subnets that cover the subnet (more or less). > >>> > >>> I suspect that you're currently in the campus. But I am > >>> not sure which part of it. I know your name. I can construct > >>> your HUMID. My phone has a list of 5 locations (subnets) where you > >>> (and your phone) is likely to be found. It sends a packet to the > >>> IPv6 addresses: > >>> > >>> subnet_prefix1 | 64bithash(Bob Hinden) > >>> subnet_prefix2 | 64bithash(Bob Hinden) > >>> subnet_prefix3 | 64bithash(Bob Hinden) > >>> subnet_prefix4 | 64bithash(Bob Hinden) > >>> subnet_prefix5 | 64bithash(Bob Hinden) > >>> > >>> If you are really in the campus, I can reach you > >>> even if DNS or your MIPv6 home agent is down. > >>> > >>> We can replace the word "campus" with building, or village or city if > >>> we wish. > >>> > >>> Now, imagine that we are in Paris. I suspect (or I am sure) that > >>> you're > >>> currently in this city. I may even know in which part of Paris > >>> you're currently located (this is the case for my friends who live > >>> here > >>> for example). I have to reach you but your MIPv6 home > >>> agent is unreachable. There are two possibilities: > >>> First, my phone may have learned the subnet prefixes that cover > >>> Paris (as I traveled in Paris... more or less). I can send packets > >>> to: > >>> > >>> subnet_prefix1 | hash(Bob Hinden) > >>> subnet_prefix2 | hash(Bob Hinden) > >>> ... > >>> subnet_prefixn | hash(Bob Hinden) > >>> > >>> Secondly, I can ask Google. > >>> Google has a map of the world, and all information that comes along. > >>> In the new world of wireless IPv6 internet, Google will probably have > >>> the map of wireless IPv6 subnet prefixes that covers the world. What > >>> is the > >>> quality of service in that subnet, how much it will cost? etc.. > >>> Google > >>> will tell me. > >>> > >>> So since you're unreachable using existing techniques, my phone > >>> asks me: > >>> > >>> Want to search Bob Hinden? (I say yes). > >>> Enter location: (I say Paris, or choose a more precise location > >>> in a map on the screen of my phone). > >>> > >>> My phone downloads the lists of subnets that cover your location > >>> from Google and starts searching you. > >>> > >>> Searching Bob Hinden. This will take a while... > >>> > >>> I take my coffee. 5 minutes later my phone beeps and says: > >>> > >>> Located Bob Hinden, calling him.. > >>> > >>> I'm happy because, I could reach you although your home agent is > >>> down (or another problem). > >>> > >>> === > >>> > >>> The above examples may or may not convince you. But the first one at > >>> least > >>> (with single subnet) is really easy to do. In my personal opinion, > >>> the others > >>> are also possible (why not?). > >>> > >>> Please recall that all the IETF needs to do is to answer: > >>> > >>> John Smith > >>> johnsmith > >>> john smith > >>> etc. > >>> > >>> which human name format should be used to construct a HUMID?? > >>> > >>> The rest is application layer software work, making the phones > >>> more intelligent etc.. This is not too difficult. > >>> > >>> And, perhaps, your phone will more likely be connecting people ;-) > >>> > >>> Thanks! > >>> > >>> pars > >>> > >>> > >>> > >>> > >>> Selon Bob Hinden <[EMAIL PROTECTED]>: > >>> > >>>> Pars, > >>>> > >>>>>> Ignoring for now if this is good or bad idea, but you might look > >>>>>> at > >>>>>> > >>>>>> > >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name- > >>>>>> lookups-15.txt > >>>>> > >>>>> > >>>>> It looks like ICMP name lookups can also be used to do the same > >>>>> thing. > >>>>> However, I couldn't understand why I would use a side protocol > >>>>> (i.e. an ICMP protocol). > >>>>> > >>>>> My proposal uses basic IPv6. BTW, the draft is now available at > >>>>> the IETF site: > >>>>> http://www.ietf.org/internet-drafts/draft-mutaf-ipv6humid-00.txt > >>>>> > >>>> > >>>> My suggestion was to look at the mechanisms in this document. It a > >>>> lot more specific than just saying "hash(John Smith)". > >>>> > >>>>>> There is a mechanism there to create multicast addresses based on > >>>>>> a > >>>>>> host name that might be a starting point. > >>>>>>> > >>>>>>> I would like to configure an interface ID > >>>>>>> hash(ParsMutaf| 1) and if it collides > >>>>>>> hash(ParsMutaf| 2) etc.. > >>>>>>> > >>>>>>> You can try reach or locate me > >>>>>>> by sending a packet to (please do not > >>>>>>> hesitate): > >>>>>>> > >>>>>>> subnetprefix | hash(ParsMutaf| 1) or > >>>>>>> subnetprefix | hash(ParsMutaf| 2) > >>>>>> > >>>>>> The big usage problem here is that without knowing your > >>>>>> "subnetprfix" > >>>>>> it won't be very useful. That leads me to wonder how useful it > >>>>>> would > >>>>>> be to find you. > >>>>> > >>>>> If we are in the same subnet (same building, campus, village, city, > >>>>> etc), we already know the destination's subnet prefix. > >>>> > >>>> I don't understand how knowing the building, campus, etc., helps to > >>>> know the subnet prefix. Please explain. > >>>> > >>>>>> Also, see the above referenced ID. It's not too hard to do this > >>>>>> on a > >>>>>> single link, but trying to scale this to the Internet gets very > >>>>>> hard > >>>>>> very fast. > >>>>> > >>>>> In fact, it doesn't have to scale to the Internet. We may > >>>>> know the whereabouts of the destination node. In other words, we > >>>>> may > >>>>> have a list of subnet prefixes that cover the target zone where > >>>>> the destination user lives. > >>>>> (obtained from Google for example, or another service like that). > >>>> > >>>> How does google help with this? > >>>> > >>>>> If one of the single point of failures (e.g. DNS, or Mobile IPv6 > >>>>> home > >>>>> agent) is unreachable, I can search the destination node by sending > >>>>> packets to its HUMID at different subnets where it is likely to be > >>>>> found. > >>>> > >>>> I understand your intent, but for this to be useful, there has to be > >>>> a way to learn the subnet prefix. For example, you know my name. > >>>> What is my current subnet prefix (without looking in the email > >>>> headers)? > >>>> > >>>>>> It is probably better for the earthquake scenario you > >>>>>> describe to do this at a higher level (e.g., have a website called > >>>>>> "i- > >>>>>> am-alive.org" and make it easy for people to leave messages and > >>>>>> for > >>>>>> people to search people they are trying to find out about). > >>>>> > >>>>> The "i-am-alive.org" approach may suffer from the same problems. > >>>>> I.e. it may be unreachable. In addition, who will maintain such a > >>>>> web site... Nobody cares until the disaster actually happens. > >>>> > >>>>> In fact, the disaster scenario is not the only motivation IMO. > >>>>> For example, I want to install an IPv6 testbed with 'n' machines. > >>>>> I'm not installing DNS and I'm not configuring the /etc/hosts > >>>>> files (because n times (n-1) entries would be needed). > >>>> > >>>> Seems to me if routing and forwarding is working, then DNS is > >>>> working > >>>> too. > >>>> > >>>> Bob > >>>> > >>>> > >>>>> Using HUMID, I can give IPv6 addresses based > >>>>> on imaginary human names to the machines (during installation). > >>>>> Human name is easy to remember. No need to configure stateful > >>>>> name->address mappings. I can start to ping right away. > >>>>> > >>> > >> === message truncated === > >> > >> > >> __________________________________________________ > >> Do You Yahoo!? > >> Tired of spam? Yahoo! Mail has the best spam protection around > >> http://mail.yahoo.com > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
